Safety programming and distributed development required by ISO 26262 (Part 3)
By Takao Futagami, TOYO Corporation
Distributed development brings better outcome
The development scale for an instrument like REINA-11 (discussed in Part 2) is small, and the specifications are simple – you could imagine this more easily if I say, the development scale is equal to that of a small-scale body ECU. So, in the design stage, you can achieve a sufficient ASIL if you carry out appropriate state analysis and actual time modeling using three fundamentals RateMonotonicActivation, ReactionByEvent and RunToCompletion.
On the other hand, the spec changes and program enhancements continuously occur based on the experiment results in the development phase, and many variations are rapidly derived for various destinations in the operation phase. For this reason, the safety-oriented detail design on the programming stage is important. The configuration management and traceability requirements specified in ISO26262 are required to be carried out at the same level as the safety programming. The trace and configuration management can be manually conducted in the case of a small-scale development at one location, but doing them manually could plant new defects in products when the development is carried out at several locations with large time differences. To be more specific, it is usually thought risky, for instance, to design the sensor function of a product in Tokyo and do the programming in Fukuoka (a large city in Kyushu island of Japan) and the communication function the other way around.
However, if it becomes possible to overcome the disadvantages of multi-location development by utilizing networks and tools, the development freedom and the product safety will both improve since skilled people can participate in the development regardless of their work places. In order to realize the safety programming conforming to ISO 26262, it is desirable that the quality evaluation incorporating MISRA-C is automated. This is because the declaration by a programmer to the effect that “I did the coding in compliance with MISRA-C as much as I can” is not regarded as enough compliance with ASIL. At many development sites, engineers having safety programming skills are in short supply, and just realizing the bottom line of the state-of-the-art development (e.g. code peer review) mentioned in ISO 26262 is difficult. Although this shortage of human resources was made up by a large number of execution tests in the past, from the viewpoint of ISO 26262, this method cannot fully guarantee the code safety. Any ASIL has a review mechanism, and the review evidence is required to be recorded. The companies having enough skilled engineers to spare for such time-consuming tasks are quite rare.
In order to automate this troublesome process, we have prepared a real-time quality evaluation environment. In this environment, anyone in the development team can monitor the program quality in real time on a daily basis and can exchange opinions online with their manager for improvement. It is natural that the requirements for development change due to the results of the performance/operation tests at the system level – the requirements and design conditions also change during the development period. Adding traceability to these changes is also time-consuming for engineers in the field. We therefore have also implemented, in the development of REINA-11 source code, a mechanism for managing these changes in a coherent way. With this mechanism, it became possible to trace which design/source code was revised/tested from such changes as real-time requirement changes for the controllability measurement and calibration process changes.
Having concluded in developing REINA-11 that it is appropriate to put a well-known OA tool in the frontend and put a full-fledged configuration management tool on the backbone, we have put together a server-client system with commercial tools and open source tools.
What we got
Under this development environment, we outsourced software development to a programmer who had skills for the embedded programming but not for the MISRA-C programming. The figure below shows the metric change in the MISRA-C quality of the code.
It has become clear that it is possible to perform effective distributed development in terms of both the cost and the concurrent development, when a programmer who is not familiar with MISRA-C but can develop programs of a certain quality level works together with a programmer acquainted with MISRA-C.
The distributed development has been done in the multi-country development and the large-scale development. However, it was difficult to benefit from the distributed development in the past due to the costs required for the server operation and for the specialists to prepare tool environments. Now, it has become clear that even small-scale teams can use operable distributed environments thanks to today’s highly-advanced ICT environment.
We are thinking of providing distributed development environments for ISO 26262 compliance as our solution in the future in addition to REINA-11.
To be continued
Takao Futagami specializes in risk analysis at TOYO Corporation, Polarion Software’s country partner for Japan
