The current and foreseeable trend, in the automotive and other industries, is an increasing level and scope of automation. A challenge is to ensure that the increasingly complex functions are developed with safety in mind. The nominal capability of the system shall be adequate to realise the function, and the system must also be capable of safely handling adverse and fault conditions. Additionally, there must be:

Conformance to an adequate process.

We believe that any safety process must rest on top of solid foundations that include sufficient A-SPICE capability and an adequate quality management system. We have experience in developing, implementing and auditing development processes.

Complete and consistent documentation.

For the latter, the documentation shall defensibly justify that system is acceptably safe for a specific application in a specific operating environment. A key part of this is known as a safety case: a structured argument, supported by evidence, intended to justify a claim of safety. The system must be architected keeping in mind that it must be able for a third party assessment to conclude adequate safety. Another key part is traceability e.g. of requirements, intended to justify a claim of safety.

Safety Culture.

A product is either safe or not. Not achieving safety can be e.g. due to lack of resources in the project or lack or understanding at the management level. Here we can apply our experience and assist a client to improve safety culture and make products with are both safe and efficient.

Blind Brake – A Case study

Here we present a case study that is based on work performed for an Automotive OEM and can represent an “easy case”. A similar study could be done for another type of vehicle e.g. truck+trailer combination, or a more complex scenario e.g. emergency stop with manoeuvering.

The feasibility of using pure inertial navigation during a blind brake (also known as safe stop) is investigated regarding performance from a safety perspective. In a blind brake scenario it is assumed that other sensors for the nominal navigation system, such as cameras and radars, have failed or can not be trusted. The blind brake system has the purpose of taking over the vehicle to ensure that the vehicle performs a safe maneuver and comes to a safe state. It is assumed that the simplest safe maneuver and safe state is hard braking along the current trajectory, i.e. the safe state of the vehicle is zero speed within the current road lane.

Using mathematical models of gyroscopes and accelerometers (as part of an Inertial Measurement Unit – IMU), together with a standard inertial navigation algorithm and large numbers of simulations, statistics of navigation errors during blind brake are derived. Also, sensitivity to initial conditions at beginning of the blind brake is investigated and quantified using the same scheme. It is assumed that the IMU-sensors, used in the blind brake function, are of state-of-the-art consumer technology, i.e. most likely possible to classify for automotive grade within the near future. Further, we assume that the IMU architecture in the experiment consists of six independent measurement units with median voting.

Scenario parameters: Vstart = 120 km/h. Brake deceleration = -5 m/s^2. We can note that such high deceleration (braking) is, although generally possibly in a passenger car, at best difficult to achieve by a human driver.

Results

The diagram gives the probability of a certain maximum lateral displacement at the end of the blind brake maneuver. This implies the “lateral error” in the figure above. Note that this is defined as the perpendicular distance between the center of the road to the center of the vehicle in the actual position. The goal is to stay within the lane during the blind brake scenario. Note that to reach “ASIL-levels” of probability, we are looking for probabilities of lower than 10E-5 (ASIL A). With 10E-5 probability we can guarantee at most 9 cm lateral deviation at the end of the scenario, i.e. zero speed. Note that these results are valid only for perfect initial conditions, e.g. zero or known sensor drift. If the assumed braking deceleration is lower then the lateral deviation will be approx 3.1 m at the same probability as above.

The red line is simulation evaluation of the scenario that have been carried out. The blue line is the analytical result from the continuous function. We can note that the continuous probability function, in the form of a normal distribution, follows the tail extrapolation where numerical data is not available (requires too many simulations).

Probing further and conclusions

The above results assume perfect initial conditions, i.e. that the sensor error in the IMU is zero at the start of the scenario.

Navigation error sensitivity to initial condition tolerances was then studied. It was found that e.g. the factor between final lateral displacement and initial lateral acceleration is 22.2. The factor between final lateral displacement and initial lateral speed is 6.7. This implies that an initial acceleration measurement error of e.g. 0.1 m/s^2 leads to a final lateral error of 2.22 m, and that an initial speed measurement error of e.g. 0.1 m/s leads to a final lateral error of 0.67 m.

One main conclusion is that it is indeed possible to reach sufficiently low probabilities for dangerous navigation errors that are satisfactory from a safety perspective. Another conclusion is that the sensitivity to initial condition errors impose requirements on the nominal sensor suite that might be hard to fulfill.

Qamcom can contribute to system development and system safety at several different levels:

• In-house development: part of or an entire work package; executed mainly at Qamcom premises. This is the preferred setup and includes governance, engineering and coordination with other (in house or external) disciplines; for example sensor-fusion design and SW-implementation.
  • Governance & Engineering consulting: This includes working with
    • System and Safety Management for development teams. This is a senior function which can be offered in combination with project management.
    • Concept: HARA, Functional Safety Concept, Technical Safety Concept and design, Safety Analysis (FTA, FMEA), etc.
    • Technical System Concept: We are used to being involved hands-on in development projects where we contribute to System architecture. Through our experience of developing safety critical systems (including AD/ADAS), we are familiar with Safety Concepts for sensor fusion architecture and feature allocation. We have experience of functional analysis and safety anal ysis of sensor fusion architectures.
    • Software & Hardware: We have experience of both software and hardware development in the automotive domain, including products with AUTOSAR.
  • Mentoring: We can provide e.g. seminars and workshops, with deep technical knowledge and experience.
• Confirmation measures: These include review (work product), assessment (product) and audit (process). Here we take the role of an independent third party to provide e.g. a Functional Safety Assessment & Audit or review of Safety Case. Through our partners we can also provide accredited variants of these services.
• Supplier Quality Assurance: We have experience in assurance of quality from both supplier and customer perspective. We have applied e.g. ISO/IEC 25051 to software component (SQuaRE).
• Process development: We have lead the creation and refinement of development processes and guidelines that fulfill ISO 26262 and A-SPICE. We can also perform gap analysis with the goal of implementing change in an organisation.
• Process audit: We perform functional safety audits and Automotive SPICE assessments. We can offer a Certified Principal Assessor for ISO 15504/Automotive SPICE.
• Research: Maintaining and cutting edge services require participation in research projects. Here we are currently involved in several national and international research projects. Topics include sensor systems and system safety in autonomous / cooperative vehicles.
• Training: We are able to give training on various safety related topics (including ISO 26262, A-SPICE, System architecture and Safety Culture) for a various audience, e.g. management, system and engineering.