Linux内核认证的商业模型考虑

Regulations on automotive products require compliance with safety standards such as ISO 26262 (“Road Vehicles - Functional Safety”). ISO 26262 defines four Automotive Safety Integrity Levels (ASIL): ASIL A (the least restrictive), ASIL B, ASIL C and ASIL D (the most restrictive). The entire system, its hardware and its software from the virtualization solution up to the applications, needs to be certified to be integrated in production vehicles.

IVI typically requires ASIL A or no certification, Instrument Cluster and Telematics typically require ASIL B and more advanced functions such as ADAS and digital mirrors require ASIL C or D.

ISO 26262 suggestions a classic systems engineering approach to software development and provides regulations and recommendations throughout the product development process from conceptual development through decommissioning. Automotive device makers must document and follow their ISO 26262 certified development process. This process provides checkpoints to ensure correctness of design through comprehensive verification and validation. During the development process artifacts are created at every stage to document product design and verification, track change history of work items, show full traceability of testing based on product requirements, provide proof of process control and report process compliance as needed to certification authorities.

However, open source development projects prioritize the value of working software (i.e., “code first approach”) over that of comprehensive documentation. This raises the question: ”Can a safety-certifiable software element be developed using open source development practices?” There are many ways to answer this question but the short answer is no. That’s why no large scale open source project has yet achieved safety certification under the ISO 26262 or IEC 61508 set of standards.

An argument can be made that taking an open source software element through safety certification after development is possible if the TCB is small. A relatively small (<10K SLOC) software element could be snapshot (forked) and taken through an effort to reverse engineer requirements and validate the testing effort for certification. The result of such an effort would be a certified open source software element that would have to be managed as a new (forked) product. From this point, all changes going forward would have to be managed with the same rigor required for a safety certifiable software element. In process, this is equivalent to managing a commercial software element. The following questions would then arise: 

- Who covers the costs of the required artifacts during design, development and testing?
- Who is the gatekeeper for changes after safety certification?
- Who covers the cost of long term support?
- Will the product be monetized? If so, what are the licensing terms?
- Who bears for the liability of the solution?