Define safe operating concept of AS
The safe operating concept (SOC) specifies sufficiently safe operation of the AS within the operating context defined by [B], [D] and [E] taking account of the identified hazardous scenarios from [XX] at Stage 2. The SOC shall include a definition of system-level safety requirements that specify how the AS must behave in order to provide sufficient mitigation for the hazardous events. The system safety requirements may be specified for the AS using either natural language or more formalised representations. Whatever representation is chosen, of most importance is that the requirements are clear and unambiguous.
Note 10 - Requirements syntax
There is existing good practice for requirements specification that can be used to guide the specification of system safety requirements as part of the SOC, such as [32] which provides a generic requirements syntax:
<optional preconditions> <optional trigger> the <system name> shall <system response>
In addition to five templates for different requirement types:
Ubiquitous requirement These are requirements that always hold and therefore have no preconditions or trigger (sometimes referred to as invariants). These requirements should have the form: The <system name> shall <system response>
Event‐driven requirement These are requirements that are initiated when, and only when, a triggering event (such as a change in the operating environment) is detected at the system boundary. These requirements should have the form: When <optional preconditions> <trigger> the <system name> shall <system response>
Requirements to handle unwanted behaviour These requirements are a variant of the event‐driven requirements that specifically deal with unwanted events (such as failures). These requirements should have the form: If <optional preconditions> <trigger>, then the <system name> shall <system response>
State‐driven requirement These are requirements that are valid while the system is in a defined state. These requirements should have the form: While <in a specific state> the <system name> shall <system response>
Optional feature requirement These are requirements that are valid only in systems that include a given feature or capability. These requirements should have the form: Where <feature is included> the <system name> shall <system response>
Requirements with complex conditions Combinations of keywords When, While and Where can be use to build complex expressions to specify more complex As behaviours. For example: While the robot is moving, when a person is present, the robot shall issue an audible warning
A structured syntax approach such as that described above provides a method for mitigating against syntactic ambiguity.
Mitigating against semantic ambiguity requires ways to ensure that the meaning of words and phrases is clearly defined within the relevant context and that only that meaning is used. This can be achieved through the use of domain or project specific dictionaries or through developing context‐specific ontologies. These should include definitions of concepts and elements included in the ODM.
Example 17 - Autonomous car braking requirement Automotive
The SOC for an autonomous car includes the following safety requirement: “The AV shall maintain sufficient distance between itself and any vehicle in front in order to provide enough time to react if the car in front suddenly brakes.” This requirement has been specified in order to mitigate the hazardous event of the autonomous car colliding into the rear of another vehicle. For such a requirement, the distance can be calculated for different driving speeds based upon a number of assumed properties such as the minimum and maximum braking performances of the cars and the frictional coefficient of the road surface (see [42] for details of such calculations). These assumptions must be validated and explicitly documented as part of the assurance case.
Example 18 - SOC for autonomous car on construction site Automotive
The SOC for an autonomous excavator operating on a construction site includes the following safety requirement: “The excavator shall ensure maximum tilting angle is never exceeded.” This requirement has been specified in order to mitigate the hazardous event of the excavator toppling whilst digging [41]. This could occur due to an incorrect configuration of the excavator whilst digging on uneven or unstable ground or as a result of resistance to the bucket.
Example 19 - Autonomous insulin infusion pump Healthcare
The SOC for an autonomous insulin infusion pump used in a busy intensive care unit treating multiple patients concurrently may contain the following safety requirement: “The alarms and warnings function of the autonomous insulin infusion pump shall not unnecessarily distract or disturb ICU nurses from their other tasks”.
Note 11 - System-level safety requirements
The safety requirements defined as part of the SOC should be defined with reference to the system‐level behaviour of the AS, that is behaviour that is visible on the boundary of the AS, rather than referring to any particular sub‐system or component. For instance, the safety requirement relating to rear collision in Example 17 should not be written as a requirement on the braking system, but, as is shown, on required behaviour of the vehicle as a whole. This requirement and its assumptions may then lead to safety requirements being derived upon the braking system through a consideration of the system design later in the lifecycle (see Stage 5).
In addition to specifying system safety requirements, as part of the SOC it may also be necessary to define a reduced operating domain (ROD). As shown in Figure 15, a ROD is a definition of additional constraints on the ODM in order to reduce the operational scope of an autonomous capability under certain conditions. By operating in a ROD, the intention is that the AS is not exposed to scenarios that may lead to hazardous events under those defined conditions.
There are a number of reasons why a ROD may need to be defined. Often a ROD will be defined with respect to a particular system state where it would be unsafe to operate within the entire scope of the ODM. This may often be in response to a particular system or component failure mode.
Figure 15: Defining a Reduced Operating Domain
Example 20 - Autonomous passenger shuttle Automotive
If there is a failure of the long range object detection sensors on an autonomous passenger shuttle, the vehicle enters a reduced operating domain that requires a low maximum operating speed for the vehicle. This enables the vehicle to transport the passengers to a safe location, but to do so without increasing the risk of collision whilst relying only on short range sensing capability.
Example 21 - Autonomous insulin infusion pump Healthcare
If there is a data communication failure between an autonomous insulin infusion pump, and the centralised electronic patient healthcare records system, the autonomous pump may be prevented from increasing or decreasing the rates of insulin infusion until either communications are restored, or action is taken by a healthcare professional.
Although RODs may be identified early in the lifecycle, it is likely that RODs will often be formulated or revised later in the lifecycle in response to understanding gained through later activities such as hazardous failures identified in [BB]at Stage 6.
Note 12 - Sufficient mitigation for hazardous scenarios
In order to define an SOC that provides sufficient mitigation for the hazardous scenarios under the specified conditions (including failures modes), there is generally a choice as to the safety strategy that is adopted:
- The AS continues to provide all of the Autonomous Capability (AC) under those specified conditions but a ROD is defined that limits the scope of operation under which that AC is provided.
- The AS continues to operate under the same ODM but the AC is limited.
- A combination of 1) and 2) is adopted.
Example 22 - Autonomous car in emergency roadworks Automotive
An autonomous car driving on a highway enters a zone with emergency roadworks in place. There are different safety strategies that could be adopted under these conditions. The car could continue to operate fully autonomously, but the maximum allowable speed could be reduced (Strategy 1). The car could continue to operate up to the normal speed but only provide lane-keeping capability, handing other control to the driver (Strategy 2). Or the car could have both its speed constrained as well as restricting its capability to lane keeping only (Strategy 3).
