From this context emerged VirtuOS, a research project in Berlin. In this project, the Technical University of Berlin, the Fraunhofer Institute FIRST, and OpenSynergy found that avionics safety standards (e.g. DO-178B) are fundamentally comparable to the safety standards for the development of automotive software (e.g. ISO 26262). This comparability is what allows avionics software to be applied, and provides assurance that a certified avionics component can be used in the automotive industry. The final report of the project will be published in April 2012. Its key message:
The DO-178B standard for the certification of software systems in aircraft describes the targets for processes, results, and interaction with the certification authority necessary to develop flawless software for use in aircraft. The ISO 26262 norm also details standards for developing safety-critical systems for vehicles to ensure functional safety.
Both DO-178B and ISO 26262 assume that functional safety can be ensured by taking appropriate error prevention steps. As a first step, similarities and differences can be examined in the following areas:
• Processes and lifecycles: What is the projected lifecycle, and what processes will be accomplished during this lifecycle? What requirements must these processes meet?
• Work results: As part of these processes, work results, i.e. documents and the final software product, are generated. In general, these form the basis for confirmation measures and product release in accordance with the standards. To what extent are the work results contents required the same or similar?
• Confirmation measures in ISO 26262: Who conducts the confirmation measures, and to what extent does the standard require autonomy of the inspecting authority? What types of confirmation measures are designated?
The results of the comparison lead to the conclusion that the development processes for aircraft technology and the automotive industry are fundamentally identical.
Avionics provides benefits for automotive software
Despite a few differences, for example that ISO 26262 demands measures for field operation, and that there are no certification authorities for ISO 26262, it is still possible to represent the assumed software lifecycle and most of the work results so that previous certification in accordance with avionics standards is beneficial for automotive software development in accordance with ISO 26262.
So there is no fundamental obstacle to the comparability of safety standards. On the contrary: studies conducted in the context of VirtuOS show that nearly all artifacts from DO-178B can be re-used for development in accordance with ISO 26262.
Establishing the comparability of safety standards opens the door for components from one of the industries to be used in the other. The findings from this research project show that two worlds that seemed so far apart can actually converge. The VirtuOS research results can thus lead to greater synergy between the aviation and automotive industries.
One example of that is COQOS, the standards-based software platform already mentioned. With it, OpenSynergy has made the microkernel technology used in avionics available for use in the automotive industry.
OpenSynergy's approach of integrating a microkernel from aircraft technology into an automotive software platform is completely new. COQOS is thus both an example and a trailblazer for the transfer of avionics components into software systems for cars. This re-usability saves carmakers considerable development costs, improves functional safety, and makes safe vehicle technology available at a reasonable price.
The left part of Image 3 shows the typical system design that can be generated by using COQOS. It shows clearly that several very different functions can be integrated through one µOS. The µOS is based on a microkernel. That insures the safe separation of the various functions.
The right side of the image shows that the architectures for IMA-based systems are based on the same principle.
Aircraft don't use multicores for the Level A parts. They are even afraid to use RTOS for the very critical parts (which I think is a mistake).
The difference is very simple: about 100000 people die in cars each year (even Europe has 35000). Only 500 die in an airplane worldwide.
ASIL level D (the highest for automotive) is the second highest level (SIL3) as defined in IEC-61508. They dropped SIL4 when defining ISO_26262. ASIL D is more or less a supervised fault detection (OK, you could call it SIL 3.5). If a failure is detected, it moves the system to a so-called fail-safe state (like limiting the engine to 1000 rpm). How safe is that at high speed on the highway?
Granted, multicore is used for the lower levels (e.g. anything that is not really safety critical). And that's why the title is misleading. If the automotive industry would apply the same process and rigor as avionics, then I would agree. But technology itself is not making cars safer. The main reason for using multicores is not safety, it's cost reduction. Of course, when you do this, partitioning is a must-have. But this is not aircraft specific. It is a standards safety supporting technique. Add then the complexity and the common mode failure risk, and how much is safety really improved vs. using dedicated processors?
The whole idea is ti NOT re-certify everything when an application (in this system called partition) is changed. The middleware is certified independently from the partitions and each partition is certified independently from the others. The idea is to permit several levels of safety on the same platform, thus reducing cost (and complexity) for the part not requiring a high level of reliability. So, the over-design may be reduced.
Also, AUTOSAR have increased the complexity (and resources) needed from the platform. But it provided far greater advantages in flexibility, cost reduction, fault isolations, separation of concerns...
Multicore, multiprocessors, SoC are extremely complex and will be more and more unmanageable. But the desired functionality is also increasing. It still requires something to provide designers high-performance resources, quality assurance but also ease of use. Hypervisors are only a step in this direction. Not final, not perfect, but still useful and far more important than the added resources consumptions.
And some hypervisors are still relatively simple. I suggest you to look at ARINC 653 in avionics (the APEX part) or OKL4 for small devices. ARINC 653-based systems have been certified under DO178 at an A level. Some have been certified EAL 7.
And, finally, yes, the processors are often limited by the memory. But this is a limitation the designers have to live with. Anyway, most of the highest performance applications do not requires a very high level of safety. For the highest performance application with a high level of safety requirement, the CPU-to-Memory problem is not the most challenging (or first) problem. The data integrity in the complex multicore CPU architecture (CPU to cache, cache coherency... ) will have first to be looked for security and safety. This is not trivial at all.
In avionics, the multicore problems and the GPU integration are not solved yet. Only workarounds have been used... with success.
Why is this called safer?
First of all, it increases a lot the complexity (and hence the risks) as the underlying partitioning hypervisor has to timeslice through the different applications. Change one application and one has to re-examine all. Not to forget that the chip has to run a lot faster than before.
Secondly, multicore promises a lot like higher density of CPUs at a lower cost but memory accesses become more stochastic, not to speak of the common mode failure. Of course ASIL level D in automotive is still not fault tolerant (vs. DAL-A in avionics), so maybe this sector cares less?
Micro kernels gives us better stability and security.Now is the time to start research to use it in automobile applications because lot of electronic monitoring and control are being introduced in the cars. Especially in the Hybrid vehicles.
Many of the technology that first starts in defense then go to consumer or automotive applications. That's interesting about virtual operating systems within a single processor. I see that's a way to reduce the hardware usage. I think this perhaps would be an adequate way of taking advantage of multi-core technology. One core per OS?
Join our online Radio Show on Friday 11th July starting at 2:00pm Eastern, when EETimes editor of all things fun and interesting, Max Maxfield, and embedded systems expert, Jack Ganssle, will debate as to just what is, and is not, and embedded system.