Adds 6 vendor parsers under codec/parser/vendor/guangdong/ implementing the Guangdong "燃料电池汽车数据接入技术规范 v1.0" extension typeCodes that the city's data ingestion platform sends inside V2016 frames: 0x30 GdFcStackBlockParser §7.2.3.4 表 13/14 fuel-cell stack 0x31 GdFcAuxiliaryBlockParser §7.2.3.5 表 15/16 auxiliary system 0x32 GdFcDcDcBlockParser §7.2.3.6 表 17 DC/DC 0x33 GdFcAirConditionerBlockParser §7.2.3.7 表 18 air conditioner 0x34 GdFcVehicleInfoBlockParser §7.2.3.8 表 19 vehicle info 0x80 GdFcDemoExtensionBlockParser §7.2.3.14 表 27 demo data extension Each parser uses ProtocolVersion.V2016 + its respective typeCode and is strictly Guangdong-spec layout, not the GB/T 32960.3-2025 fuel-cell stack layout (the two share typeCode 0x30 but have different field orders and extra cell-voltage statistics in the Guangdong variant). Field model in InfoBlock.java gains: - GdFcStack(stackCount, stacks: Stack(workState, waterTempC, h2InletPressureKpa, airInletPressureKpa, airInletTempC, max/min/avg cell voltage ids and values, cellCount, frameCellStart, frameCellCount, frameCellVoltagesV)) - GdFcAuxiliary(subSystemCount, subsystems: Subsystem with air compressor, hydrogen pump, water pump, PTC, low-voltage battery) - GdFcDcDc, GdFcAirConditioner, GdFcVehicleInfo, GdFcDemoExtension InfoBlockType enum gains the matching GD_FC_* constants. Tests: - GdFcParserTest covers the 4 fixed-length parsers (0x32/0x33/0x34/0x80) with hand-crafted bytes asserting field-by-field decoded values. - 0x30/0x31 are variable-length and will be exercised end-to-end via the body parser integration test in a follow-up. Spec doc: adds reference/广东燃料电池汽车示范应用城市群综合监管平台-...pdf (v1.0.220822) used as the source of truth for these parsers. These parsers exist as classes only; no Spring beans are wired yet. Wiring + decoder context plumbing land in the next commit. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
4.8 MiB
4.8 MiB