Improvement: Add Flatbuffers as configuration alternative

[arsibo]

What

As discussed in https://github.com/orgs/eclipse-score/discussions/472?sort=new#discussioncomment-15063052 point 3. Migration from JSON to Flatbuffers shall be showcased in communication module.

How

No response

Estimates for realization

Category

• Affects Detailed Design

Requirements / Architecture

• Requirements / Architecture are not affected by this change?

[arsibo]

@OliverHeilwagen

[crimson11]

@arsibo
Q: Did you discuss the safety related topics already? I.e. in the json-config case, the expectation is:

• mw_com_config.json of an ASIL-B qualified app gets reviewed/verified by the app developer (4 eyes principle or whatever)
• the json parser used to parse (within mw::com::impl) it, is required to be safety-qualified.

If we want to keep the safety concept, then (looking at the liniked PR above):

• the json-transformation (python code) done on the original mw_com_config.json needs to be "qualified" ... or would we rather expect, that we have people checking/verifying the "converted" json?
• the flat-buffers converter then running on the converted json needs to be "qualified"

What is your view?

[OliverHeilwagen]

@crimson11

In S-Core we have not yet discussed the details of the safety related tasks. Within ETAS we have FlatBuffer functionality ISO26262 certified.

The safety related topics were briefly shown in the presentation for eclipse-score/score#1935 FlatBuffers_on-board_configuration.pdf.
On a broad level we see the following activities as necessary:

• Mirror FlatBuffer repository in S-Core, similar to what has been done for nlohmann.
  • Apply TSF
  • Verification of required Flatbuffer headers / rust crates (reader + verifier)
  • Basic tool qualification flatc
    • Perform end to end tests (expect values from json in code for basic schema functionalities)
    • Perform fault injection tests (invalid json files (missing elements, wrong elements, values out of range) -> fail to generate binary)
• Tool qualification flatc
  • Code generation (expectation TCL1):
    • Treat as manual written code -> Perform module specific end to end verification (expect values from json in code)
  • Buffer generation (expectation TCL2):
    • See above
    • Module specific schema tests -> Perform end to end verification / fault injection (expect values from json in code)

The qualification of the python conversion tool should be depending on the migration scenario. Since we expect a migration phase in which both json and flatbuffer are available to allow for a smooth transition, the tool should be in scope.

[crimson11]

The qualification of the python conversion tool should be depending on the migration scenario. Since we expect a migration phase in which both json and flatbuffer are available to allow for a smooth transition, the tool should be in scope.

Or we already force a "renaming" of the json-properties, so that this conversion isn't needed ....