Virtual Open Systems Scientific Publications

Introduction

In mixed-criticality domains, the term functional safety has become a topic of high importance. Indeed, functional safety generally means that malfunctions of the operating system, which contain mission-critical tasks, that lead to any kind of threat or even accident have to be avoided or mitigated. Therefore, it is fundamental in the field of functional safety to identify and understand potential risks and failure causes of a system. If ideally all potential failure causes are known and the consequences understood it is possible to define countermeasures. Thus, failures are detected before a hazardous event occurs and the safe state is initiated with the needed of functional safety reaction.

The safe states can importantly vary according to the final application as well as the injuries which might be led by the system failure without countermeasures. As every application is different and has its own particularities and thus potential failure causes and related safe states, the functional safety analysis is very interesting challenges.

In this context, many functional safety standards have been established to define the main requirements to fulfill during the development of critical systems in order to ensure a high level of reliability in the critical systems. The main functional safety standard is the IEC/EN 61508 that defines the basis for functional safety developments for E/E/EP (electronics, electronic or programmable electronic) applications. In addition, the IEC/EN 61508 is expanded by additional industry sector specific standards, such as the ISO 26262 Road vehicles Functional Safety which has been specially defined for the automotive domain (see section II-A).

Indeed, the automotive industry is rapidly evolving towards the connected autonomous vehicle which will considerably increase the hardware/software complexity, while functional safety will be a topic of high importance since critical features will be controlled by electronics components (e.g., autonomous driving, etc.). Thus, the ISO 26262 defines a functional safety lifecycle for each automotive product development phase, ranging from the hazard analysis and risk assessment to design, implementation, integration, verification, validation and production release.

In this context, Virtual Open Systems has developed VOSYSmonitor, a hypervisor based on ARM TrustZone that enables the consolidation of mixed-critical Operating Systems (e.g., Linux-KVM along with a RTOS) on a single ARM-based platform with special attention to safety and security. This software technology has been developed as a Safety Element out of Context (SEooC) in compliance with the ASIL-C requirements of the ISO 26262 standard and it ensures freedom from interferences for the safety critical partition.

As a mater of fact, VOSYSmonitor is a perfect solution to support a modern generation of car virtual cockpit where the In-Vehicle Infotainment (IVI) system and the Instrument Digital Cluster are consolidated and interact on a single platform. Indeed, traditional gauges and lamps are replaced by digital screens offering opportunities for new functions and interactivity. Vehicle information, entertainment, navigation, camera/video and device connectivity are being combined into displays. However, this different information does not have the same level of criticality and the consolidation of mixed-critical applications represent a real challenge that must respect the stringent requirements of the ISO 26262 functional safety standard.

Since VOSYSmonitor is only a software component, the paper will detail the definition of safety functionalities by applying the ISO 26262-6 Product development at the software level. After a summary of the ISO 26262 standard and the different technologies involved in the Section II, we present related work and emphasize the advantages and drawbacks of existing solutions compared to our design in Section III. Then, a more-detailed presentation of the safety features of VOSYSmonitor is presented in Section IV. These features are divided into two parts: detection and recovery mechanisms. The performances of these mechanisms is evaluated in Section V, by measuring the latency between a fault detection and the entry to the mitigation state. Finally, Section VI summarizes this work findings and directions for future works.