Spec reference
x-FuSa spec §2.4.1:
The standard value is a canonical lowercase id, used identically in .fusa.json, the envelope, Finding.standard, requirements, and gap-reports — it is an enum value, never a display string... There is no "ISO 26262" form anywhere in the JSON.
What actually happens
This repo's own committed fmea.json and tara.json (dogfooded by PR #72) both emit a free-text display string in the standard field instead of the canonical id:
$ python3 -c "import json; print(json.load(open('fmea.json'))['standard'])"
IEC 60812:2018 / ISO 26262-5
$ python3 -c "import json; print(json.load(open('tara.json'))['standard'])"
ISO/SAE 21434:2021 Clause 15
Traced to cmd/cfusa/cmd_fmea.c (two occurrences, both literal):
" \"standard\": \"IEC 60812:2018 / ISO 26262-5\",\n"
(lines 421 and 477), and the equivalent literal in cmd/cfusa/cmd_tara.c.
Notably, cmd/cfusa/cmd_safety_case.c's safety-case.json gets this right ("standard": "iso26262"), so the convention is already correctly implemented elsewhere in the same PR — fmea/tara are the outliers.
Why this matters
Per §2.4.1, standard is meant to be an unambiguous enum value everywhere (iso26262, iso21434, …) so cross-tool/cross-language tooling can route/group on it without string-matching free text. "IEC 60812:2018 / ISO 26262-5" and "ISO/SAE 21434:2021 Clause 15" are neither valid ids nor even single standards — they're citations of the reference documents FMEA/TARA are based on, conflated with the field meant to identify the project's governing standard.
Suggested fix
Emit the canonical id ("iso26262" for fmea, "iso21434" for tara, since the FMEA is done "per IEC 60812:2018 (generic) or the AIAG & VDA FMEA Handbook (2019) (automotive)" and TARA is "per ISO/SAE 21434:2021 Clause 15" — pick whichever this tool's .fusa.json standard says, or default to the ISO 26262/21434 id since that's what the human-readable citation already names). Keep the handbook citation, if wanted, in a separate field or in prose (ratingScale already exists for FMEA's rating-table name).
Spec reference
x-FuSa spec §2.4.1:
What actually happens
This repo's own committed
fmea.jsonandtara.json(dogfooded by PR #72) both emit a free-text display string in thestandardfield instead of the canonical id:Traced to
cmd/cfusa/cmd_fmea.c(two occurrences, both literal):" \"standard\": \"IEC 60812:2018 / ISO 26262-5\",\n"(lines 421 and 477), and the equivalent literal in
cmd/cfusa/cmd_tara.c.Notably,
cmd/cfusa/cmd_safety_case.c'ssafety-case.jsongets this right ("standard": "iso26262"), so the convention is already correctly implemented elsewhere in the same PR —fmea/taraare the outliers.Why this matters
Per §2.4.1,
standardis meant to be an unambiguous enum value everywhere (iso26262,iso21434, …) so cross-tool/cross-language tooling can route/group on it without string-matching free text."IEC 60812:2018 / ISO 26262-5"and"ISO/SAE 21434:2021 Clause 15"are neither valid ids nor even single standards — they're citations of the reference documents FMEA/TARA are based on, conflated with the field meant to identify the project's governing standard.Suggested fix
Emit the canonical id (
"iso26262"forfmea,"iso21434"fortara, since the FMEA is done "per IEC 60812:2018 (generic) or the AIAG & VDA FMEA Handbook (2019) (automotive)" and TARA is "per ISO/SAE 21434:2021 Clause 15" — pick whichever this tool's.fusa.jsonstandardsays, or default to the ISO 26262/21434 id since that's what the human-readable citation already names). Keep the handbook citation, if wanted, in a separate field or in prose (ratingScalealready exists for FMEA's rating-table name).