John Lindland presents the third in a series of articles that set out to describe the intent of functional safety, and how to design for functional safety, drawing on content from a soon-to-be published book, Design for Functional Safety, The Concept Design Phase.
The focus of this (third) article is to provide a useful understanding of ISO 26262 Part 3’s item definition work product requirements (e.g., 5.4.1 and 5.4.2). This conversation begins in the following paragraph. There are at least two or maybe three item definition bodies of knowledge that are beyond this article and will be covered in the next series of articles. These future topics are: 1) How to define the representative road segments of any operating domain definition. 2) How to understand NHTSA’s pre-crash scenario for the representative road segments for each of the ODDs. This is used to define sensor requirements, object tracking, object prediction, and so on. Pre-crash scenarios are the consequences of an item that is not capable. 3) An introduction to using the 7FM functional block diagram to model the concept of the item in its relationship from sensors to vehicle-level functions as well as the vehicle feedback information. This also models all functions that are inputs and outputs of the item. It includes all elements that might be shared between different autonomy solutions. This helps define functional priorities – under what specific circumstances do some functions have priority over others?
The importance of a good item definition is overlooked too often and it becomes a superficial technical writing and editing step. When this happens, the HARA (hazard analysis and risk assessment) will likely become a superficial analysis. this is followed by a strawman functional safety concept. In the end, a company can argue that they have satisfied requirements but they have not satisfied the intent of these requirements. The result is that the system design phase does not have well-defined requirements against which to design. An Albert Einstein quote is very important to proactive designing and Design for Functional Safety: “If I had an hour to save the world, I would spend 59 minutes defining the problem and one minute finding solutions.” Every deliverable in ISO 26262 is satisfied directly by 7FM Design for Functional Safety. All requirements are seamlessly woven together by the goal of designing flawless function sequences. Every deliverable adds to the creation of a high-quality, reliable and safe autonomous design. The item definition defines the product that will be analyzed by the hazard analysis and risk assessment. The item definition needs to feel like a physical design that is theoretically exposed to every representative road segment in its ODD. The HARA and its complex relationships with the driving environment will be used to develop an extremely strong functional safety concept (a rough draft system design).
Terms:
AV: autonomous vehicle – the vehicle that contains the item being designed.
ODD: Operating Domain Definition.
HazOb: hazard object – vehicle, pedestrian, or a pedal cyclist.
Hazard: causing harm to a human.
HARA: Hazard analysis and risk assessment.
VLF: Vehicle Level Functions.
DDT: Dynamic Driving Tasks.
An item definition is a living document that is updated after each work product is completed such as the HARA, functional safety concept, system design phase, hardware design phase, software design phase, and production, service, support and decommissioning.
ISO 26262 Part 3: Overview
The concept phase has three work products: (1) the item definition; (2) the HARA; and (3) the functional safety concept. All three of these have been covered briefly in previous topics. They will be covered again but in a more structured and detailed manner in the following pages or articles. At the end of the item definition, the item should seem to be a design that already exists in form and function in the minds of all the key designers and managers of the project.
The item definition needs to describe a clear concept-level design and how it is expected to behave in each of its operating modes throughout its ODD. The item definition explains the functions, sequences and inter-relationships from sensor (starting functions) through the system and to the vehicle-level functions (the actuators – the final functions). It explains all inputs, interfaces and outputs. This is required before any risks associated with its commands can be assessed. The item identifies all representative road segments in the ODD in relationship to their complexities and dynamic driving tasks. It provides the basis of determining the risk of misbehaving vehicle-level functions, the pre-crash scenario they can create, and the exposure to causing harm. There are many types of road structures and each have their own road grade relationships to different types of destinations (e.g., crossroads, interchanges, home, business, school, industry, etc.) and they each have their own interrelations with pedestrians, pedal cyclists and other vehicles. The probability that a hazard is present at the same time that a pre-crash scenario is created by the AV is the criticality of the design (severity and exposure). This criticality can be managed by the controllability of the vehicle by a driver or by vehicle autonomy. If the system warns the driver, they can intervene and avoid a pre-crash scenario. Otherwise, the determination of an appropriate safe response is the responsibility of autonomy.
The item definition will remain a work in progress. As more is learned about the design, the item definition is expected to be updated. For example, the HARA will show that many considerations were missed or not fully explained by the initial item definition. This will lead to their inclusion into the functional safety concept. A large number of new design weaknesses and their solutions will be found in the system phase design. These weaknesses will be overcome in the hardware and software design phases. All requirements will be physically tested and validated. Validation tests will have failures and new solutions. All new functions, their interrelations, their dependencies, their interactions with other items and the vehicle system interfaces need to be described.
The risks of vehicle-level functions need to be described for each representative road segment within the scope of the ODD. For example, a forward collision on a freeway is different than a forward collision on a minor arterial roadway or state highway. How a specific scenario becomes a pre-crash scenario differs between all representative roadways. How HazObs are exposed to pre-crash scenario changes with each representative road segment. The requirements of vehicle-level function responses are different so there are different effects of vehicle-level function failure modes. Once solution might satisfy its functional safety requirements in one road segment but only partially meet the requirements for a different or more complex representative road segment. In others, a requirement might be missed so the design failed to mitigate a specific risk. How the item is defined along with its ODD and representative road segments can help produce a very complete analysis.
A weak item definition directly leads to a HARA that does not assess and identify inappropriate and misbehaving vehicle-level functions that can cause harm. Hazard objects are vehicles of any type, pedestrians of any nature, and pedal cyclists of any configuration. The fault states/failure modes of these vehicle-level functions are linked to potential hazardous pre-crash scenario. The HARA produces automotive safety integrity levels (ASILs) for the VLFs based on each failure mode’s pre-crash scenario. The ASIL is defined by exposure to humans, severity of specific pre-crash scenario, and the ability of a driver to take control of the vehicle and avoid a pre-crash scenario (controllability). Each pre-crash scenario, linked to its VLF, receives safety goals and one or more functional safety requirements (FSR). The requirements from ISO 26262 Parts 3, 4, 5, 6 and 7 are based upon each function’s assigned ASIL. Function Designs that have work product that satisfies their ASIL requirements have an absence of unreasonable risks. The work product becomes the evidence/safety case for each function.
The VLFs, their ASILs, the safety goals, are used to develop the functional safety concept (FSC) and functional safety requirements (FSR). The FSC is a detailed rough draft of the future system level design. It is produced in response to the item definition and all the risks found during the HARA. The vehicle-level ASILs and safety goals are assigned to the elements of the concept level design that produce the vehicle-level function commands. Potential faults, their detection and safety mechanisms are defined. Fault Tolerant Time Interval times are considered for each concept level fault. The structure of the functional safety concept is modeled by the architecture of the 7FM functional block diagram. The functions are detailed in their sequences and interrelations. Each function’s fault states are identified in a temporal fault state map. Each fault sequence can be traced to each VLF fault state, its violation of safety goals, and to specific pre-crash scenario. The ASILs of the VLFs are assigned to the function sequences in the 7FM functional block diagram that produce each vehicle-level function (sensors, through the system, to the VLFs). Each function receives the highest ASIL assigned to it after being evaluated for its role in producing each vehicle-level function. Each function receives at least one safety requirement. Every failure mode/fault state receives requirements.
The ISO 26262 Part 3 item definition requirements and what they mean will be covered first. A hands-on approach to creating the item definition will be covered in following articles. The item definition should follow the structure defined in 5.4.1 and 5.4.2. All these ideas will be expanded in future articles.
The requirements for the item definition and what they mean.
Document the requirements of the item (5.4.1).
Identify all legal requirements and national and international standards (5.4.1.a). Define the legal authority and approvals required by local, state and national government offices that will allow the AV to be driven on public roads. Define the local, state and national driving rules and regulations to which the AV must comply. Levels 1 and 2 AVs are controlled by the driver and require only normal automotive validation and approval to drive on public roads. Each country has a governing body for motor vehicles. The USA has the Department of Transportation (DOT) and the National Highway Traffic Safety Administration (NHTSA). The NHTSA has several autonomous vehicle policies that are intended to govern the design and development of autonomous vehicles for use on public roads. The NHTSA uses the Federal Motor Vehicle Safety Standards (FMVSS) to establish and manage standardized tests to validate that vehicles meet its minimum safety requirements to be driven or sold for use on public roads. Autonomous vehicle design and development companies break the integrity of the FMVSS tests when they place their systems in a vehicle. Whatever functions they control (steering, braking, acceleration or deceleration) are no longer covered by OEM FMVSS validation tests. It must be noted that the NHTSA/FMVSS does not receive and approve the FMVSS testing for any OEM automotive manufacturer. It does not enforce the autonomous vehicle policies. Noncompliance with FMVSS regulations becomes a problem to the OEMs should an accident occur and the required testing is not available for review or the required testing is found to be noncompliant. This can generate rather large fines for the automotive/autonomous manufacturing company. The same will likely be true for violation of the autonomous vehicle policies. For example, the NHTSA requests a voluntary safety report be filed with its office. This is an online submission. It must be honest and objective. Should an accident occur, it is likely that the autonomous manufacturer will be evaluated against their safety report claims. In the absence of a safety report, the autonomous manufacturing company will be questioned against the content of their policies to find what should have been voluntarily submitted to NHTSA. Since NHTSA’s AV policy identifies ISO 26262 as the appropriate standard to manage the development and deployment of AVs, it will likely lead to the evaluation of AV companies’ certification to IATF 16949 automotive quality management system (as required by ISO 26262 Part 2) as well as their compliance with ISO 17025 Calibration and Test Facility standard (as required by IATF 16949 and FMVSS). The ISO 26262-required supporting processes must be included in the IATF 16949 automotive quality management system procedures, instructions, documentations and records. Enforcement will likely be exception/accident based.
The National Conference of State Legislatures has an Autonomous Vehicles State Bill Tracking Database which can be used to identify legal approval requirements. The legal requirements become part of IATF 16949’s 8.2.2.1 Determining the Requirements for Products and Services – Supplemental.
Describe the functional behavior at the vehicle level, including the operating modes or states (5.4.1.b). Define the operating states of the AV including off, active, running and stationary, hold position, city driving, highway driving, car wash, being towed, and so on. Hazards are only directly placed at risk when the AV commands vehicle-level functions. It is important to define the states where autonomy must be prevented from commanding vehicle-level functions. It is important to define how autonomy will command vehicle-level functions in each of its active states. Autonomy that is in standby and could be activated at any moment must be immediately ready to produce safe commands upon activation. This means that standby requires continuous processing and command readiness based upon the current driving environment. For each active operational state, define the AV requirements for each specific VLF. Document the vehicle’s torque and acceleration across the full range of speed from zero to maximum AV controlled speed. Document the steering position, velocity of angle change, and the acceleration of angle change across the full range of speed to maximum AV controlled speed. Document the safe maximum braking torque from full speed to stop. These will be the commanded vehicle-level responses by autonomy.
Define the required quality, performance and availability of the functionality, if applicable (5.4.1.c). Describe the conceptual statistical lateral position capability (steering/turning). Describe the impact that AV speed has on lateral position capability. The momentum of the vehicle will have an inverse relationship in its ability to change directions. This means that as the vehicle travels faster the variation associated with lateral position will increase. Statistical capability decreases as variation increases. Describe the conceptual statistical longitudinal position capability (acceleration, deceleration, speed, braking). Describe the effect that speed has on longitudinal position capability. As velocity increases so does the AV momentum. Increased momentum will cause an increase in longitudinal variation. As the AV’s velocity increases the system latency causes proportional changes in both lateral and longitudinal position and as a result increases the variation and reduces statistical capability. Describe the maximum conceptual system latency from sensor to specific VLF responses of turning, acceleration, deceleration and braking. Describe the maximum amount of time in which the AV must fully understand its driving environment (object and event detection). This relates to a secondary/redundant autonomy function path. In other words, how long will it take to operate should an emergency occur (e.g., safety mechanism)? Describe the stopping distance as a function of speed for the vehicle. Describe the conceptual system’s latency in reaction time involved in braking and document the maximum allowable time that the system is allocated to determine the amount and nature of braking. This will be the amount of time required for sensors to provide information for object recognition and the evaluation of events that produce motion constraints. It also includes the amount of time required to estimate the expected future location, velocities and acceleration of hazardous objects and their future motion constraints. These will relate to the planned/expected paths of the AV and its time to intercept (potential crash) for each HazOb. It is associated with calculating optimal VLF response (e.g., optimal trajectory, acceleration, deceleration, steering angle path and braking). Describe the requirements for predicting pedestrian motion (e.g., which way are they going to move and why – head movement, facing direction, walking patterns, indicate different probabilities of movement?).
Availability (A) is the ratio that a system is working divided by the time it is required to work. Reliability is the length of time that the system is working. When system functions fail to operate, this is marked as a failure. The mean time between failures (MTBF) is the average time that the system is working. The length of time that the system is not working is defined by its mean time to repair (MTTR). Mean time to repair can be an automatic safety mechanism that brings the system back to full functionality. It can also be the length of time required to perform diagnostics and repair. This defines availability as a mathematical equation – or A=MTBF/(MTTR+MTBF).
Hardware ASIL assignments require that hardware hazard/failure rates are extremely low. Hardware-software interface and E/E board diagnostic failures are associated with diagnostic fault detection as well as planned safety mechanisms. Safety mechanisms are associated with fault tolerance time intervals and these are the automatic time to reroute faulty functions and achieve fully functionality. It can also be the length of time it takes a human to resume full DDT control. Therefore, safety mechanisms provide conceptional mean time to repair as it is associated with E/E hardware. The closer mean time to repair is to zero, the higher the availability. This directly relates to the FTTI and the completion of safety mechanisms.
Failure is also when the system cannot resolve a safe solution. The driving environment might be such that the system cannot determine a safe vehicle-level function. Example: if lane-centering works per specifications 91% of the time, 9% of the time it fails to resolve a solution. The driver has their hands on the wheel and on some roads where the road lines are not clear, 91% might be considered good reliability. In this example, availability is a luxury not a safety requirement; 91% of the time it is preventing lane departure, which significantly reduces several pre-crash scenario risks. On the other hand, emergency crash avoidance needs to be available 100% of the time. The ODD needs to be reviewed and the percentage of road miles that the system can resolve solutions needs to be estimated. This is divided by the total mileage of the sample roads. The ratio would estimate the expected availability of the system based on the driving environment under normal driving conditions. Statistically speaking, this means developing statistically sound sample sizes, performing calculations and inferring availability on the population (the ODD). This will be covered in depth in a following article.
Identify the constraints regarding the item such as functional dependencies, dependencies on other items and the operating environment (5.4.1.d). The design is dependent on other items, such as power from the vehicle. Redundant and emergency power might need to be part of the concept’s functional safety requirements. Systems are dependent on the vehicle-level items such as steering system, braking system, engine system, electrified powertrain system, transmission system and vehicle CAN, and body control systems such as HMI, wake-up and lighting controls. Describe operating environment requirements for system effectiveness, such as well-defined road lines, legal traffic control devices and road signage. Operational environment: describe the system requirements for response when HazObs illegally intrude into the AV’s right of way, such as another vehicle driving on the wrong side of the road, pulling out in front of the AV at the last moment, a pedestrian stepping in front of the AV at the last second, to name a few. Define the requirements for operating in less than perfect environmental conditions or limitations such as day, night, sunrise, sunset, rain, fog, snow, sleet, dust/sand storm, farm equipment on roads, city congestion, road construction, forward accidents, HazOb in the roadway, and so on. This also includes when the AV reaches the end of its operating domain definition. Its operational domain must be geofenced. An L3 highway pilot solution is limited only to the highway. It cannot be allowed to control highway exiting maneuvers.
Document all the vehicle-level functions required by the AV’s system. Document all the fault states and their respective fault codes for each of the required vehicle-level functions. Document how fault codes affect the expected vehicle-level functions.
Expand on the potential consequences of behavioral shortfalls including known failure modes and hazards, if any (5.4.1.e). From the NHTSA report DOT HS 812 745, August 2019, there are nine groups of pre-crash scenarios summarized from an estimated 5,020,000 (89%) of all police-reported crashes based on the yearly average of 2011-2015. The summarized crashes accounted for 24,534 (94%) fatal crashes; 6% of the crashes were the fault of equipment and non-driver-controlled circumstances. The nine groups contain a total of 36 specific pre-crash scenarios. The nine groups of behavioral shortfalls are loss of control crashes, road departure crashes, animal collisions, pedestrian collisions, pedal cyclist collisions, lane change collisions, opposite direction collisions, rear-end collisions and crossing path collisions. Every vehicle-level function can fail in one of seven ways and these are the seven failure modes. The consequences of each vehicle-level function’s failure modes/fault states are pre-crash scenarios. NHTSA has 36 pre-crash scenarios, each of which can be addressed through autonomy and linked to each of the seven potential vehicle-level failure modes/fault states for each representative road segment in the ODD. Some of the pre-crash scenarios relate to equipment failure and can be ignored. However, the majority of equipment failures can be monitored and predicted. This means that safety mechanisms can be activated before mechanical failures create pre-crash scenarios.
Drivers can detect that a vehicle is not responding properly and they often stop before an unsafe mechanical/system failure occurs. Autonomy can be designed to emulate a driver who is extremely aware of normal vehicle conditions and the statistical degradation of the AV’s responses. Level 3-5 autonomy solutions must avoid all NHTSA pre-crash scenarios for each representative road segment in its ODD. Table 3.5 shows a portion of the 7FM HARA worksheet. It is an analysis method that directly assigns each vehicle-level function’s seven failure modes to a pre-crash scenario. Each of these hazards has its calculated injury/fatality rates. This allows a percentage crash reduction estimate to be generated and this estimate can be validated after system-to-vehicle integration.
Each specific representative road segment will have its HazOb priori, which are the expected HazObs for each road segment. Object digital signatures must be capable of detecting each priori and they are made available from the MAP or from a match file. This means that the object’s digital signature matches can be prioritized based on the expected HazObs in each representative road segment identified in the map. Every representative road segment has expected HazOb priori. The driving risks increase and decrease as the AV transitions between different road segments. A general priori is less precise than the map/road segment priori (expected on specific road segments). For example, a controlled-access highway will have almost zero risk of having pedestrians or pedal cyclists in one of the lanes. This means that a match to pedestrians will not be at the top of the object digital signature match list. Construction would still have almost zero risk of having a pedestrian in a lane. And so on. A full example will be shared in the following HARA section/article/chapter. At the item definition, it makes sense to identify which of the 36 pre-crash scenarios will be mitigated or eliminated by autonomy (what is the expected statistical capability of avoidance?). These are objective consequences. After the HARA has been completed, the 7FM HARA analysis summary can be placed in this section of the item definition. Statistical capability edge case (single variable) and corner case (two variables) analysis can be performed to predict the safe capability of the AV.
Object recognition has shortfalls caused by non-deterministic models and their statistics/function. The weakness is that that objects change their recognition category. The same sensor data can be run multiple times and will produce different object recognitions with different categories. Any object that changes its category is unknown and cannot be used to predict behavior. Risk cannot be assigned or determined. Deep learning can be used to learn and recognize different objects. However, it requires a human in the loop until it has achieved solid statistical capabilities. It can be used to learn the relationships between objects in motion. Again, this needs a human in the loop. Deep learning is the student. The human in the loop is the teacher. Deep learning is non-deterministic and it takes too long to categorize objects as well as relationships. Deep learning is not as fast or precise as a novice driver. In autonomy, all objects are known and all object motion relationships can be defined, sensed and predicted. Sometimes there are several predictions possible for any object and the predictions can have their associated probabilities. This lack of certainty requires that L3-L5 designs have emergency path solutions that can be automatically activated by these associated probabilities. Autonomy does not have the time required and cannot accept the risks associated with deep learning and non-deterministic statistical object and event detection strategies. Non-deterministic models will cause crashes, injury and death. Non-deterministic systems turn into deterministic systems when the object characterization stabilizes. In the critical region that can affect optimal trajectory, object recognition must be stable and deterministic. All sensors have effective ranges. As objects enter the extreme effective range, they might be seen only as objects. Object tracking can begin. As the object gets closer, it can be assigned unstable and non-deterministic categories. Objects become deterministic after they fully stabilize into a specific category. Only then can they be safely used to understand objects and events. Specific object attributes can be collected and tracked and can be used to refine and predict future probabilities of behavior for each HazOb.
Document the capabilities of the vehicle-level actuators, or their assumed capabilities (5.4.1.f). Vehicle level actuators for steering, braking and throttle are all automotive safety-level actuators. Their performance curves and response times are known. The item definition must model their response times and capabilities into the system design. Autonomy must be able to model the vehicle response to these actuators. These systems all monitor their own health and produce fault codes. The fault codes and the changes in actuator responses to autonomous commands must be documented and included in the item definition and system design. The degradation in steering, braking and engine/motor responses must be incorporated into the planned safe vehicle functions commanded by autonomy. The system must fail safely before degradation reaches actuator failure.
Define the boundary of the item, its interfaces and the assumptions concerning its interaction with other items and elements (5.4.2).
Document all the elements of the item required to control VLFs (5.4.2.a). The design boundary defines the functions that enter and exit the scope of the design. The 7FM functional block diagram documents the elements of the item and their functions that are required to produce the vehicle-level functions. Elements that interface with, and provide input functions into, the item are defined. This includes relationships and dependencies with other items, some of which might be autonomous, that might be included in a vehicle’s design. The functional block diagram determines the functions that are within the boundary/scope of the item definition. All function time sequences and their interrelations from sensors through the system to the vehicle-level functions are defined.
Considering Figure 3.8.2 (below), the dotted lined boxes are outside the scope of the design team. This 7FM functional block diagram shows all the elements and their functions that are required to make the item work. Functions are placed next to the functional block that they leave. Object digital signatures are identified by the iRadar, which sends the relative positions of HazObs as well as their trajectories if they are moving. The (B) vehicle steering control module sends the current steering wheel position. This indicates the arc or lack of arc for cornering. This and the relative position of HazObs allows for the rough calculation of time to intercept (crash) with any relatively positioned forward HazOb. The (A) vehicle brake system module sends its current braking energy level. This is used to confirm that commanded braking is responsive and correct. The vehicle BSM also sends the brake system’s fault codes so 1 Controls can assess the fault code’s impact on the braking response allowed by the vehicle BSM.
The iRadar is a purchased design element that is required by the system. The iRadar would be purchased either under a supplier design interface agreement or it would be a purchased commercial off-the-shelf ASIL-certified sensor whose safety goals and safety case may or may not agree with the functional safety requirements of the item’s application. The iRadar must be reviewed to ensure that the context in which it was developed will match the context of the emergency crash avoidance’s design. This includes the required functions from the iRadar, its E/E board diagnostics, hardware-software interface diagnostics, fault codes sent to the item, and the ability for the item to perform end-to-end communication health checks and be able to be reset by 1 Controls should the iRadar stop responding. The iRadar would be a safety element [that has been designed] out of context (SEooC) from the emergency forward crash avoidance system. The iRadar’s safety case would be reviewed to ensure that it complies with all the functional safety requirements of the item under study. The E/E device 1 Controls would either be purchased elements or designed and manufactured by the team. It is within the scope of the design because the software controls are designed by the team and then integrated into the E/E 1 Controls device.
Document the assumptions concerning the effects of the item’s behavior on the vehicle (5.4.2.b). The effect that autonomy will have on the vehicle is consistent with its design intent. In the case, of the emergency forward crash avoidance system, emergency braking will occur if the driver fails to slow down and avoid hitting any forward object in its path. The vehicle has performance curves for acceleration, deceleration, braking and steering. The assumptions are that the item will send command requests to the vehicle that will be as trustworthy as a good driver. The autonomous commands will produce these expected vehicle-level commands.
Autonomy interrupts the function flow of a human driver. In normal driving mode, the functions begin with the driver controlling throttle, steering and braking. When autonomy is not active, these are passthrough functions. In other words, they pass through autonomy unchanged as transfer functions and autonomy does not send competing command requests. When the driver performs any of these functions, they must have priority over autonomy’s functions. They must override or cancel autonomy. Braking, throttle and steering must never receive conflicting function commands and they must always receive the intended safe commands. The driver has priority. Since autonomy essentially hijacks these functions, a driver would not be able to physically overpower autonomy if autonomy does not recognize the human input. The steering motor is much stronger than a human. The engine/motor has far more torque than the brakes. There is no direct physical cause-and-effect connection between the throttle and the amount of fuel/electricity that creates acceleration/deceleration.
Describe the functionality of the item under consideration required by other items and elements (5.4.2.c). How does the item under study help to produce the functions required by other items? These are the item’s functions that become inputs or hardware resources for use by other items and elements. Multiple Level 1, 2, and 3 items can be installed on the same vehicle. They will need to share electrical power, CAN and software processing functionality. They might share sensor information and the function of one item might be the exact function needed by another item. Adaptive cruise control can manage the throttle to accelerate, maintain speed or slow the vehicle. This might include controlling the braking system for stop-and-go applications. Emergency brake crash avoidance might send a calibrated emergency brake request to command the brakes for emergency stop. Lane centering might also be an option and adaptive cruise control can work at the same time as lane centering. They can be mutually exclusive. Yet, turning has an effect on the acceleration and deceleration curves and vehicle stability. The adaptive cruise control might be intelligent, which means it reads speed limit signs. As long as it does its job, lane centering will never corner at unsafe speeds. Crash avoidance that commands turning, when braking will not be enough to avoid a crash, can use the lane centering interface to send a safe turn avoidance command, and this would override or have a higher priority than lane centering’s steering. It can also override lane centering’s active state (e.g., not turned on). To do this, the crash avoidance system must have sensors to know that the area to the right/left of the vehicle is open and will remain open for the duration of the emergency avoidance maneuver. This means that the interfaces and capabilities of each item definition must be defined and how each item might use the resources of another item must become part of a design interface agreement. How other items can be used to create a function must be defined. The shared functions/resources between items must have clearly defined functional priorities.
Consider that an original item was added to a vehicle (Figure 3.8.2) and then a second item was added to a vehicle (Figure 3.8.3, above). This is the basis for requirements 5.4.2.c and 5.4.2.d. The question asks what does the item under design need from other items that have already been designed or will be designed. The ‘from-to’ and ‘to-from’ relationships can both be understood by placing both designs into a single 7FM functional block diagram (Figure 3.8.4, below). Each item can be designed to have its own hardware and the software required to produce the vehicle-level functions. This would drive up the price of the vehicle and add to the power drain on the electrical system of the vehicle. Both designs would use the same 1 Controls micro-proccing unit. Since the second item is being added, it is required to provide functionality for lane centering. The E/E device 1 Control communicates to the vehicle’s system through a CAN. The question is, does each vehicle-level function use a common CAN or independent CANs? This leads to hardware requirements. Figure 3.8.4 is a combined 7FM functional block diagram that includes both items and how their functions flow through the design. This is an example that includes only the basic functions. The black functions (verb-noun) are the original functions. The red functions are the functions required by the second item.
The functions from the iRadar and camera are mutually exclusive, as is the software in the E/E device 1 Controls, which is required to process them into vehicle-level functions. The functions required to send brake commands will have the highest priority. This means that software will need to be developed that mitigates these functions. Lane centering may or may not remain active in an emergency brake situation. Combining these two designs into a continuous stream of functions, both of which are for the purpose of controlling mutually exclusive vehicle-level functions, provides the ability for forward crash avoidance to expand its capability to command simple steering as well as braking for crash avoidance. This would be the same as a normal driver might perform (a small swerve left/right). This would create new risks that would have to be mitigated by the upgraded design.
Document the functionality of other items and elements required by the item under consideration (5.4.2.d). These are hardware and software functions that the item under study can make available as inputs to the item under study. A natural thing to consider is the vehicle control module that has already been created to support a previous item. If the item under study was the lane centering design (Figure 3.8.3), with the exception of appropriate sensor information, it would need all the resources provided by the emergency crash avoidance (Figure 3.8.2). This is the same conversation as 5.4.2.c with the exception of hardware-software interface and fault code support.
All external elements and items (outside the item’s design boundary) that interface with the item being designed are defined on the 7FM functional block diagram. Items that rely on each other must be able to signal their state of functionality. Are the functions healthy, degraded or in a failure state? Are healthy functions degrading but still meet requirements? Between control modules, and often within control modules, the end-to-end data transfer health/integrity needs to be monitored. When a control module is not responding properly, it might require a remote reset. Identify the requirements where all control modules can be reset at the request of another control module. This can be a failsafe manager. It can just as easily be a function flow matrix that will always have a module that is working and can directly request a reset of another module that might not be responding correctly. All sensors need to have the option of being reset at the request of the item.
Show the allocation and distribution of functions among the involved systems and elements (5.4.2.e). This is fully satisfied by a 7FM functional block diagram that clearly identifies all dependent functional relationships to and from the item under study (e.g., Figure 3.8.4). Clearly identify all functions and their interfaces from sensors to VLFs. This includes inputs to the item and outputs from the item. It includes power and emergency backup power. If the vehicle fails while driving, a driver can safely guide the vehicle to a stop. If the vehicle fails under a Level 4 or Level 5 solution, the item must retain full power for itself and power and control over steering and braking as a minimum. The item must be able to safely guide the vehicle to a safe parking spot off the driving surface and, if a safe off-road parking spot is not available, safely stop in lane.
Define the operational scenarios which impact the functionality of the item (5.4.2.f). Affecting the functionality of the item is identifying the limits of the item’s ability to resolve the driving environment and correctly determine a safe response (VLF). What are the limitations of the sensors? A camera and lidar cannot determine the physical mass of an object. A lidar cannot read a sign or determine GYR traffic control lights. A lidar cannot detect turn signals. A lidar and camera cannot see between vehicles. An iRadar can see through nominal sheet metal and it can detect the vehicle in front of the lead vehicle by the return signal under that vehicle or through glass. An iRadar can detect the mass of an object. Sensors can only detect what is in their field of view. Sensors cannot see over a hill. Sensors are affected by the physical position and angle of the vehicle (up/down a hill, tilting to the right/left). A vehicle has six sides. Object recognition can see any of the four vertical sides of a vehicle and detect it as a vehicle. Can object recognition resolve these four sides from every angle? Can object recognition recognize a vehicle from the top or bottom (e.g., an accident)? What are the limits of chaos that the system is designed to unravel, understand and produce a safe response? What is the maximum number of HazObs that the system can identify and track before the processing requirements slow the system down too much? Identify the most complex examples of each representative road segment in the ODD. How many objects must be detected and tracked? What are the most chaotic motion constraints? What are all the reasonably expected intrusions into the AV’s right of way? Each can be studied at different times of the day and driving complexities can be documented. These would represent the normal and expected driving challenges, which is the primary focus of the autonomy design. None of these challenges should cause autonomy difficulty. Determine the limitations of sensors, their field of view, what sensors can detect. Define the limits that sensors can achieve in separating partially occluded HazObs from each other.
The importance of a good item definition cannot be overstated. It is the controlling focus of creating a solid and statistically capable autonomous design. A solid item definition produces a HARA that can define all sensors, object recognition, object tracking, event detection and so on. Safety goals will be clear and useful for designing the system and its validation. A functional safety concept will address all the weaknesses found during the HARA and this will be a robust starting point for the system design phase. Every deliverable in ISO 26262 is satisfied directly by 7FM design for functional safety. All requirements are seamlessly woven together with the goal of designing flawless sequences of functions. Every deliverable adds to the creation of a high-quality, reliable and safe autonomous system design. The item definition defines the product that will be analyzed by the hazard analysis and risk assessment. The item definition needs to feel like a physical design that is theoretically exposed to every representative road segment in its ODD. END
For Part 2, see: FEATURE: An Overview of ISO 26262 Road Vehicle Functional Safety (Part 2) | Autonomous Vehicle International
For Part 1, see: FEATURE: The basis of ISO 26262 Road Vehicle Functional Safety – designing for functional safety | Autonomous Vehicle International