No abstract

We face two difficulties when applying ISO 26262[1] in the concept phase. ISO 26262 is the functional safety standard in the automobile field and requires strict safety requirements. Usually, it is not easy to divide requirements into safety parts and non-safety parts because they are closely connected with each other. That is, we have to perform two activities, functional development and functional safety activity, simultaneously. Other difficulty is a term item. From the definition, the item is a 'system (1.129) or array of systems to implement a function at the vehicle level'. In concept phase, we apply hazard analysis to an item, not system. The system definition comes after item definition and hazard analysis and risk assessment. So, it is hard to use the conventional methods (e.g. Failure Mode and Effect Analysis (FMEA) and Fault Tree Analysis (FTA)).To support this situation, we propose a method and a tool. Our method is an extension of knowledge acquisition in automated specification, and we also use the Goal Structuring Notation and scenario-situation matrix. The drawback of multi-diagrams approach is the difficulty of maintaining the integrity of data, but the linkage mechanism of our tool provides the good navigation measure to transit a node of a diagram into the other node of a different diagram.Although we aim to support the scope of part 3 of ISO 26262, we believe this approach is not limited to the automobile field and can be used in a wide range of fields

No abstract

There is no standard method for describing the Operational Design Domain (ODD) in automated driving vehicles. There are many elements in the operating domain, including the external environment, and it is necessary to connect them with the internal state of the automated driving system. Its content ultimately requires the user's understanding. The description method of this ODD is summarised from the aspect of safety. Consistency with standards and guidelines will also be considered.

No abstract