[Author]

Renhong WENG, AI safety and security investigator

It is going into be summer in 2020, with Coronavirus existing with us, tears and bloods, the world had seen huge tumors and bads times in the past half years.

Never mind, today, it is planned the SEooC development introduction from now on.

First: SEooC introduction

we can explore some original meanings from ISO 26262-2018:

safety-related element which is not developed in the context of a specific item.

So, SEooC first is element, which can be system, or systems, or component, unit, part, etc.

in the following two ways, the SEooC will exist:

1. where development environment or profile not clear

2. when Elements are used in aggrandized within industry, different ECUs, then no specific requirements allocation to whom

Someone will say SEooC will help us to cost down functional safety efforts and time, and there are following methodologies which can do like this, look at following:

As above, SEooC can be used in the 3 types of SW development.

Second: SEooC vs qualification of SW/HW

SEooCs differ from qualified software components described in ISO 26262-8, Clause 12 and evaluated hardware elements:

- An SEooC is developed, based on assumptions, in accordance with the ISO 26262 of standards. it is intended to be used in multiple different items when the validity of its assumptions can be established during integration of the SEooC.

- Qualification of SW components and evaluation of hardware elements address the use of pre-existing SW components or HW elements for an item developed under the ISO 26262 series of standards.

From above, we can judge following:

- system controllers, ECUs, microcontrollers, SW implementing one communication protocol like CAN, or AutoSAR will be SEooC, due to their requirements is in sometimes in assumptions, and not developed via certain contexts

- LINUX or Android, etc open source softwares not the SEooC, due to their development rely highly on system itself, and deeply using contexts from system, item etc.

Third: SEooC development process

first we go to ISO 26262-2 for requirements of tailoring lifecycle:

a) the development of the safety element out of context shall be based on a requirement specification that is derived from assumptions on an intended use and context, including its external interfaces; and

b) the assumptions on the intended use and context of the safety element out of context shall be validated when the element is integrated in its target application.

second is for the SEooC we get it from the ISO 26262:

Forth: SEooC development example

Derived out from Ref.2, suppose we are discussing the Piloted Parking via App (L4). For this scenario the driver is outside the vehicle and controls the vehicle via an App on the mobile phone. The environment is also less constraint (limited to parking lots) and the vehicle speed is very low. For such functionality specific concepts are require that overrule the gear shift lever and parking lock mechanisms.

we discuss about following 3 safety goals and its allocation in the powertrain architecture:

(1) SG_02 is related to internal functions of the transmission system only and will therefore not be affected by the application of Piloted Parking via App (L4).

(2) SG_05 also relating to transmission system internal function only, but the additional SEooC constraint of the transmission and L4 PPA feature(chip will be SEooC too) integration

(3) SG_01 will be affected by App parking scenario, as well the App parking scenario vehicle Radar chips.

System architecture of automatic transmission system as following:

above all, the FSR allocated to the Parking pilot will be:

This article will stop here, in the next article, we will start from the parking pilot system and then to internal AI chip for the SEooC.

[REF]

Ref.1  ISO 26262-2018

Ref.2  Integrating SEooC Components in Highly Automated Vehicles