FSD321: Software design and development¶
Motivations¶
The software supplier is the entity that develops the software. The software user is the entity responsible for the complete system in which the software is used. The embedded software supplier (JOBTech) is contracted by SSP North which is the software user. Some non-safety software is also developed by SSP North. Finally, configuration by the limited language is made by either SSP North, dealers or end customers. Thus, SSP North has the full responsibility for the main product, while configuration responsibilities is divided. The configuration responsibility is further clarified in detail in the manual |
a) The overall functional structure is aimed to be fairly high level, focusing on what to do rather than how to do it. The different kinds of tasks to be performed are separated into modules where each type of activity has its own module, such as the fast interrupt module. Each module has a well-defined interface. The comparatively high-level language C goes a long way to avoid unnecessary complexity compared to assembler. b) The information exchange between modules is described by FSD304: System architecture description. Design assumptions are expressed in the requirements and data structures are expressed in the implementation language. Classical flow charts express functionality and sequencing. Both high level flow charts and low level more implementation specific flow charts are used. Finite state diagrams are used to get a picture of the internal state of different modules. c) Flow charts are done per module. This gives a structural view of which modules that exist in this relatively small system. Finite state diagrams show how these modules cooperate, and thus how the safety related software/system behaves. d) Comprehension is ensured by using traditional and widely used formats, e.g. C, flowcharts and finite state diagrams. Most developers are already familiar with these tools and if not, there is a wealth of easily accessible information that will persist far into the future. e) Validation entirely depends on the safety requirements and the finished system. For the purposes of validation, the completed system is regarded as a black box whose functionality is tested. Validation is therefore independent of design. The modular structure facilitates verification reviews. |
Validation and integration tests have been specified concurrently with the design, necessitating ongoing consideration of testability. Tests that require a HW modification has been minimized. This system is not intended to be modified in place in the installation. It is a component that is replaced and sent for service. Features for in place modification are thus not relevant. |
The separation of the system into several parts with well-defined interfaces and the use of a high level language both facilitate modification of the software by providing modularity, information hiding, encapsulation and abstraction. |
The design is described using classical flow charts, finite state diagrams and annotated C header files restricted by the MISRA-C rules. The first two have been used for design specification purposes for a long time due to their clarity. The automotive industry has expended great efforts to make the last perfectly unambiguous. |
Almost all software in the CPUs is considered to safety relevant, thus separation is not an issue. No operating system is used which greatly reduces the concurrency problems we could have experienced. |
Self-monitoring and fault detection of internal errors in the safety related software is achieved by using these techniques: * CRC in combination with flow control and watchdog, as described in EN 61508-7:2010, A.9.4. This method detects deadlocks, tight busy-loops and incorrect execution flows. * exception on access of invalid memory. * The two critical tick interrupts use HW timers to assure they are called in a timely manner These faults will result in that the safety CPU will go into a safe state. |
All software in the safety CPUs is considered safety related as the parts that control UI and other non-critical parts are integrated with the main software. |
Only SIL3. |
No software modules recognized with systematic capability below the safety integrity level for the safety function. |
Not applicable, systematic capability for the software modules not calculated. |
Not applicable, software made from scratch, pre-existing software not used. |
Not applicable, software made from scratch, pre-existing software not used. |
a) see FSD211: Limited variability language. b) see FSD211: Limited variability language and safety manual. Only trained people shall do configurations. c) data structures have extensives protection with CRCs, magic words, length indications, software compatibility checks. d) see FSD120: System design requirements specification. |
Responsibility lies within SSP North and JOBTech, see section General requirements 7.4.2.1 in this document. Further, the safety application is fairly small, and the responsibility for the entire software development, including selection of tools, lies on one software designer, even if other designers are consulted. As a consequence of this, there is no division of responsibility that has to be documented. |
As note 1, clause 7.4.5 in EN 61508-3:2010 suggests, we have combined the software system design and the architectural design (see FSD304: System architecture description), due to the small size of our safety related application. See FSD304: System architecture description for a detailed description of the selected techniques and measures. |
Since the project to develop this safety function is fairly small, the amount of people is quite limited, and work closely together. Any findings that are done during software development are fed back to hardware development and, if applicable, documented in FSD114: 61508-1 E/E/PE system safety requirements specification. |
Software on-line support tools are not used. |
Software off-line support tools are considered to be a coherent part of the development activities. The main software off-line support tools used are: text editors, static code analyser, call walker, debugger and compiler. See FSD303: Techniques and measures. |
Selection and design of software off-line support tools have been justified and used by experience of several years of software development for products with safety approvals according to EN 61508:2010. |
Software off-line support tools in class T2 are typically CPPCheck (static code analyser). This tool is widely known, used, and comes with heavy product documentation. Software off-line support tools in class T3 are typically GCC for ARM compiler. GCC tools are widely known and come with heavy product documentation. |
No failure mechanisms affecting the executable software have been identified, reported or experienced. Reliance is placed on the CPPCheck, (T2) and GCC tools (T3). |
Software off-line support tools from GCC are recognized worldwide. Several years of successful usage shows that these tools conform to their specification. |
Not applicable. Conformance, based on successful usage, is sufficient. |
Compiler and linker that we use are from GCC, developed to be fully compatible with each other. No other off-line tools use other tools output/input. |
a) GCC tools used which are recognized and accepted worldwide. b) Only defined coding language features used. c) Considered to match the characteristics of the application. d) We mostly use C, and C is a rather strictly typed language. Debugger and static code analysis used, are used to statically analyse and find errors in the code. e) CPPCheck is used for static code analysis. CPPCheck is configured to check to source code for MISRA-C compliance. |
Not applicable, 7.4.4.10 considered to be fully satisfied. |
Programming language C subset is used, according to MISRA-C compliance. |
a) The version control system used (git) stores information on who wrote every line of the code. b - c) Description of modules and parameters/return values to/from functions are described in source code header files. d) See bullet a) above. |
There is one tool that generates data structures from a definition file. This is a trivial conversion, and the tool is evaluated before development and continously for correctness. |
a) Only support tools of class T3 applicable. The build tool uses a configuration file which includes the version of the GCC tool kit (which in turn pin points versions of each tool inside the tool kit). b) See a). c) The build file includes information about which source code files were used when making the binaries. The build file also includes which build options that were passed to the compiler at build time |
Only qualified, complete and official versions are used. Specified versions are required to build software. Also see EN-61508-3 clause 7.4.4.13 (MOTIVATION_321_213) bullet a). |
Mainly GCC tools are used, which are compatible with each other. CPPCheck for C/C++ supports C code. |
a) - b) New versions of software off-line support tools (and relevant change logs and release notes) are closely evaluated and validated before being used live. As the project advances closer to a complete product, a far more restrictive approach should be taken towards accepting a new support tool (compiler) since the implicit test time in the project will be less. |
Responsibility lies within SSP North and JOBTech, see section General requirements 7.4.2.1 in this document. Further, the safety application is fairly small, and the responsibility for the entire software development, including selection of tools, lies on one software designer, even if other designers are consulted. As a consequence of this, there is no division of responsibility that has to be documented. |
Software safety requirements (FSD319: Software Safety Requirements Specification) and software validation (FSD150: Validation tests of modes, power supply, and configuration) are partly reused from previous projects. Thus, the Software safety requirements specification, the E E PE system safety validation planning and the software section of the E E PE system safety validation test specification are available before start of detailed design and development phase starts. There is no architecture, just this single component, so as suggested in clause 7.4.5 note 1 system design and architectural design are combined. |
The main aim of the design is modularity, abstraction and clean interfaces. The result is visible in the design description, modelling and the source code. |
See FSD304: System architecture description, FSD124: GUI and Compiler function requirements, module tests and integration tests and FSD300: Software Module Tests. |
Software system integration tests are specified in FSD124: GUI and Compiler function requirements, module tests and integration tests, FSD150: Validation tests of modes, power supply, and configuration and FSD300: Software Module Tests. |
All code is reviewed by an individual before being merged into the main branch. See FSD320: Code review. |
The entire code shall be reviewed according to the verification procedure, see documents Software verification plan and Software verification reports. |
The software design and development is documented in this document, FSD304: System architecture description, FSD124: GUI and Compiler function requirements, module tests and integration tests and FSD300: Software Module Tests. The documentation is available to all developers and reviewers. The documentation is also available to the SSP North management and the certification body. |