Datarouter Implementation Inspection Checklist
|
status: draft
security: YES
safety: QM
|
||||
Implementation Inspection Checklist#
Purpose#
The purpose of this checklist is to collect the topics to be checked during implementation, i.e. in the detailed design and the source code of the units.
The checklist shall be agnostic to which programming language is used. Differences shall be treated by linking to C++ or Rust specific documentation.
Conduct#
As described in the concept doc_concept__wp_inspections the following “inspection roles” are expected to be filled:
content responsible (author): <contributor/committer explicitly named here, who is the main author, as can be seen in config mgt tooling>
reviewer: <contributor/committer explicitly named here, who is the main content reviewer, must be different from content responsible>
moderator: <committer explicitly named here, who is is the safety manager, security manager or quality manager initiating the inspection>
Checklist#
It is mandatory to fill in the “passed” column with “yes” or “no” for each checklist item and additionally to add in the remarks why it is passed or not passed. In case of “no” an issue link to the issue tracking system has to be added in the last column (if not solved in the same issue). See also doc_concept__wp_inspections for further information about reviews in general and inspection in particular.
Scope: this checklist covers the Datarouter daemon (Datarouter (comp__datarouter), score/datarouter).
The parts of Logging: architecture and SW design about mw::log are context and were not compared with the code.
Review ID |
Acceptance Criteria |
Guidance |
Passed |
Remarks |
Issue link |
|---|---|---|---|---|---|
IMPL_01_01 |
Is the design according to guidelines? |
see gd_temp__detailed_design and doc_concept__imp_concept (e.g. are the views done with the proposed UML diagrams) |
yes |
Detailed design structure and UML views were reviewed against the template.
The diagrams pass the |
|
IMPL_01_02 |
Is the implementation according to specification? |
Check if the linked component requirements are fulfilled and detailed design also matches architecture description. |
no |
The detailed design matches the component architecture (units, interfaces, see Detailed Design). Component requirements without a test link were linked to existing tests. Following issues need to be addressed:
|
Requirement tests: #319. Other points: To be added. |
IMPL_01_03 |
Are the design decisions and constraints documented? |
Check also for plausibility of these. |
no |
The decisions and constraints in Detailed Design were inspected against the code and refer to diagrams. Following issues need to be addressed:
|
To be added |
IMPL_01_04 |
Are all external libraries used by the component specified in the detailed design? |
Check the automated dependency analysis. Also make sure ASIL rated units also only use ASIL rated libraries. |
no |
Dependency and FFI metadata are maintained in Bazel. The direct
dependencies outside of bazel query 'let l = kind(".*_library", //score/datarouter/...) except attr(testonly, 1, //score/datarouter/...) in labels(deps, $l) except //score/datarouter/...' --keep_going --output=label_kind
Those without the bazel query 'let l = kind(".*_library", //score/datarouter/...) except attr(testonly, 1, //score/datarouter/...) in (labels(deps, $l) except //score/datarouter/...) except attr(tags, FFI, labels(deps, $l))' --keep_going --output=label
The Datarouter is QM, the rule “ASIL units only use ASIL-rated libraries” does not apply to it. Dependency/configuration findings remain:
|
To be added |
IMPL_02_01 |
Are the static and dynamic code analysis reports verified for violations? |
All violations in ASIL related code must be justified. This includes the checks of coding guidelines. |
no |
Refer to the generated verification report and revision-specific CI results. A host run (Linux x86_64) of the unit tests, clang-tidy, ASan/UBSan/LSan, TSan and Memcheck shows no findings. Line and branch coverage are 82.6 % and 76.1 %. The QNX tests were not run. Following issues need to be addressed:
|
|
IMPL_02_02 |
Do manual checks, that are derived from the coding guideline, find no safety critical error? |
Check this for the programming language used (e.g. C++ <link_to_checks_list>, Rust <link_to_checks_list>) |
no |
The manual MISRA C++:2023 checks are not done yet. The Datarouter has no Rust code. Following issues found in C++ guideline:
|
To be added |
IMPL_03_01 |
Do the UID of the interface in component documentation match the implemented interface names of the unit? |
Compare interface UIDs (which contains the interface name) in component architecture/detailed design documentation with public interfaces in source code (e.g. API headers, traits, public types/functions). |
no |
The detailed design maps each architecture interface to its source code interface (Detailed Design). Following issues found:
Action: decide whether to adapt the UIDs, rename the interfaces or accept the mapping as a documented deviation. |
To be added |
IMPL_03_02 |
Are detailed design and source code consistent and is the respective traceability established ? |
Check if available static and dynamic design diagrams and the textual descriptions match the code (e.g. naming of interfaces, units, functions/operations/messages, data types). Check if the folder/file names of the units and its source code matches the intended functionality. For example if a unit is named “communication” it should not contain code for “data processing”. |
no |
The texts of Logging: architecture and SW design and Remote Logging implementation details, the README, the units table and the diagrams were compared with the code. The session, watchdog, early disconnect and configuration session diagrams match. Following issues found:
|
|