WO2017187997A1 - 車両制御システム検証装置、車両制御システム、及び車両制御システム検証方法 - Google Patents

車両制御システム検証装置、車両制御システム、及び車両制御システム検証方法 Download PDF

Info

Publication number
WO2017187997A1
WO2017187997A1 PCT/JP2017/015067 JP2017015067W WO2017187997A1 WO 2017187997 A1 WO2017187997 A1 WO 2017187997A1 JP 2017015067 W JP2017015067 W JP 2017015067W WO 2017187997 A1 WO2017187997 A1 WO 2017187997A1
Authority
WO
WIPO (PCT)
Prior art keywords
safety
function
control system
vehicle control
architecture
Prior art date
Application number
PCT/JP2017/015067
Other languages
English (en)
French (fr)
Inventor
敏史 大塚
櫻井　康平
Original Assignee
日立オートモティブシステムズ株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 日立オートモティブシステムズ株式会社 filed Critical 日立オートモティブシステムズ株式会社
Priority to EP17789284.1A priority Critical patent/EP3451174B1/en
Priority to US16/086,666 priority patent/US11151076B2/en
Priority to CN201780011147.2A priority patent/CN109074299B/zh
Publication of WO2017187997A1 publication Critical patent/WO2017187997A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00—Digital computers in general; Data processing equipment in general
    • G06F15/76—Architectures of general purpose stored program computers
    • G06F15/78—Architectures of general purpose stored program computers comprising a single central processing unit
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60T—VEHICLE BRAKE CONTROL SYSTEMS OR PARTS THEREOF; BRAKE CONTROL SYSTEMS OR PARTS THEREOF, IN GENERAL; ARRANGEMENT OF BRAKING ELEMENTS ON VEHICLES IN GENERAL; PORTABLE DEVICES FOR PREVENTING UNWANTED MOVEMENT OF VEHICLES; VEHICLE MODIFICATIONS TO FACILITATE COOLING OF BRAKES
    • B60T17/00—Component parts, details, or accessories of power brake systems not covered by groups B60T8/00, B60T13/00 or B60T15/00, or presenting other characteristic features
    • B60T17/18—Safety devices; Monitoring
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60T—VEHICLE BRAKE CONTROL SYSTEMS OR PARTS THEREOF; BRAKE CONTROL SYSTEMS OR PARTS THEREOF, IN GENERAL; ARRANGEMENT OF BRAKING ELEMENTS ON VEHICLES IN GENERAL; PORTABLE DEVICES FOR PREVENTING UNWANTED MOVEMENT OF VEHICLES; VEHICLE MODIFICATIONS TO FACILITATE COOLING OF BRAKES
    • B60T8/00—Arrangements for adjusting wheel-braking force to meet varying vehicular or ground-surface conditions, e.g. limiting or varying distribution of braking force
    • B60T8/32—Arrangements for adjusting wheel-braking force to meet varying vehicular or ground-surface conditions, e.g. limiting or varying distribution of braking force responsive to a speed condition, e.g. acceleration or deceleration
    • B60T8/88—Arrangements for adjusting wheel-braking force to meet varying vehicular or ground-surface conditions, e.g. limiting or varying distribution of braking force responsive to a speed condition, e.g. acceleration or deceleration with failure responsive means, i.e. means for detecting and indicating faulty operation of the speed responsive control means
    • B60T8/885—Arrangements for adjusting wheel-braking force to meet varying vehicular or ground-surface conditions, e.g. limiting or varying distribution of braking force responsive to a speed condition, e.g. acceleration or deceleration with failure responsive means, i.e. means for detecting and indicating faulty operation of the speed responsive control means using electrical circuitry
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60W—CONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W50/00—Details of control systems for road vehicle drive control not related to the control of a particular sub-unit, e.g. process diagnostic or vehicle driver interfaces
    • B60W50/02—Ensuring safety in case of control system failures, e.g. by diagnosing, circumventing or fixing failures
    • B60W50/0205—Diagnosing or detecting failures; Failure detection models
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60W—CONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W50/00—Details of control systems for road vehicle drive control not related to the control of a particular sub-unit, e.g. process diagnostic or vehicle driver interfaces
    • B60W50/02—Ensuring safety in case of control system failures, e.g. by diagnosing, circumventing or fixing failures
    • B60W50/0225—Failure correction strategy
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B19/00—Programme-control systems
    • G05B19/02—Programme-control systems electric
    • G05B19/04—Programme control other than numerical control, i.e. in sequence controllers or logic controllers
    • G05B19/042—Programme control other than numerical control, i.e. in sequence controllers or logic controllers using digital processors
    • G05B19/0428—Safety, monitoring
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B9/00—Safety arrangements
    • G05B9/02—Safety arrangements electric
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/22—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/22—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing
    • G06F11/25—Testing of logic operation, e.g. by logic analysers
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F30/00—Computer-aided design [CAD]
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60W—CONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W50/00—Details of control systems for road vehicle drive control not related to the control of a particular sub-unit, e.g. process diagnostic or vehicle driver interfaces
    • B60W2050/0001—Details of the control system
    • B60W2050/0002—Automatic control, details of type of controller or control system architecture
    • B60W2050/0018—Method for the design of a control system
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/20—Pc systems
    • G05B2219/24—Pc safety
    • G05B2219/24109—Execute first diagnostic, service program before normal control program
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/20—Pc systems
    • G05B2219/26—Pc applications
    • G05B2219/2637—Vehicle, car, auto, wheelchair

Definitions

  • the present disclosure relates to a vehicle control system verification device, a vehicle control system, and a vehicle control system verification method.
  • Patent Document 2 discloses an improved method for designing and verifying a safety-oriented system. According to Patent Document 1 or 2, it is possible to inspect and verify the contents of architecture design and implementation for requirements related to safety and reliability.
  • Patent Documents 1 and 2 either comprehensively verify safety function requirements from the safety analysis results (also referred to as safety analysis information), and multiplicity in reliability (multiplicity is described in Patent Document 1). The verification of the relationship between safety functions is not disclosed. Therefore, the techniques disclosed in Patent Documents 1 and 2 are not sufficient for verifying each function of the vehicle control system. The present disclosure has been made in view of such a situation, and provides a technique for comprehensively verifying the safety of function design based on a safety analysis result.
  • the vehicle control system verification device includes a storage device that stores a program for verifying the safety of the logical architecture of the vehicle control system, and reads the program from the storage device to increase the safety of the logical architecture. And a processor to be verified. The processor executes a process of verifying whether or not the logical architecture has a logical function corresponding to the safety analysis result, based on the information on the safety analysis result.
  • FIG. 1 It is a figure showing a schematic structure of vehicle control system verification device 100 by an embodiment of this indication. It is a figure which shows the example of schematic structure of the vehicle system 1 provided with the vehicle control system of evaluation object. It is a figure which shows the example of the physical architecture of the vehicle control system. It is a figure which shows the internal structural example of ECU302. 2 is a diagram illustrating an example of parameters of a physical architecture 20. FIG. It is a figure which shows the structural example of the logical architecture 601 of a vehicle control system (for example, 1st vehicle control system 2). 6 is a diagram illustrating an example of parameters of a logical architecture 601. FIG. It is a figure which shows the structural example when a logical architecture is arrange
  • step 1501 It is a flowchart for demonstrating the detail of a safety function cooperation verification process (step 1501). It is a figure which shows the example of a safety control model. It is a figure which shows the example of a check of the arrangement
  • the vehicle control system verification apparatus comprehensively verifies the safety of the functional design and the appropriateness of the arrangement based on the given safety analysis result, and whether or not the necessary requirements are satisfied. It verifies the presence or absence of cooperation between safety functions. Specifically, the vehicle control system verification apparatus according to the present disclosure determines whether or not the logical architecture of the vehicle control system has a logical function corresponding to the safety analysis result based on the information of the safety analysis result (FTA) given. Validate.
  • the logical architecture may be constructed based on information on the safety analysis result. This is because the verification of the safety function at the time of design is to design the architecture so as to satisfy the safety requirements of the FTA and check whether it actually satisfies the safety requirements of the target FTA. .
  • the vehicle control system verification device verifies whether the physical architecture of the vehicle control system satisfies the safety level and the multiplicity required by the logical architecture.
  • embodiments of the present invention will be described in more detail.
  • embodiment demonstrates the verification apparatus of a vehicle control system mainly and it is suitable for verification of a vehicle control system, application to other systems is not prevented.
  • (1) First Embodiment In the first embodiment, there is a safety function required by the FTA in the logical architecture of the vehicle control system, and the logical architecture is arranged on the physical architecture of the vehicle control system. The verification of whether the physical architecture satisfies the required safety and multiplicity is disclosed.
  • FIG. 1 is a diagram illustrating a schematic configuration of a vehicle control system verification apparatus 100 according to an embodiment of the present disclosure.
  • the vehicle control system verification device 100 includes a function placement unit 101, a safety verification unit 102, and an architecture quantitative evaluation unit 103.
  • the function placement unit 101 receives, for example, the logical architecture 601 and the physical architecture 20 and executes a process of placing the logical architecture 601 on the physical architecture 20 as in the function placement example (see FIG. 8).
  • the safety verification unit 102 receives an architecture after function arrangement and safety analysis information (for example, FTA: Fault Tree Analysis (see FIG. 9)) 900 as an input, and is an architecture designed according to the safety verification flow proposed in the present disclosure. Verify the safety of Then, the safety verification unit 102 outputs the safety verification OK or the safety verification NG and the reason thereof to the function arrangement unit 101 as the verification result. The verification result may be directly output to the architecture quantitative evaluation unit 103.
  • FTA Fault Tree Analysis
  • the architecture quantitative evaluation unit 103 receives the verification result of the security of the architecture, performs a quantitative evaluation mainly on the architecture whose safety verification is OK, and outputs the evaluation result. As described above, the vehicle control system verification device 100 performs verification and evaluation of the vehicle control system.
  • the vehicle control system verification device 100 can be realized by a computer having a processor (such as a CPU) and a memory (such as a ROM and RAM).
  • a processor such as a CPU
  • a memory such as a ROM and RAM
  • the function placement unit 101, the safety verification unit 102, and the architecture quantitative evaluation unit 103 are configured by programs, and the processor is configured to read and execute various programs from a program memory (ROM). Details of the logical architecture 601, the physical architecture 20, the function placement unit 101, and the security verification unit 102 will be described later.
  • FIG. 2 is a diagram illustrating a schematic configuration example of the vehicle system 1 including the vehicle control system to be evaluated.
  • the vehicle system 1 corresponds to an automobile or the like, and has a vehicle control system inside.
  • the vehicle system 1 includes, for example, a first vehicle control system 2, at least one communication device 3, a second vehicle control system 4, at least one drive device 5, at least one recognition device 6, and an output.
  • a device 7, an input device 8, and a notification device 9 are provided.
  • two vehicle control systems (the 1st vehicle control system 2 and the 2nd vehicle control system 4) were mentioned as an example, it is not restricted to two. Moreover, you may employ
  • the first vehicle control system 2 includes, for example, an in-vehicle network (CAN: Controller Area Network, CANFD: CAN with Flexible Data-rate, Ethernet (registered trademark), etc.) and a controller (ECU: Electronic Control Unit, etc.).
  • the first vehicle control system 2 is connected to the second vehicle control system 4, the communication device 3, the drive device 5, the recognition device 6, the output device 7, the input device 8, the notification device 9, and the like. It is configured to send and receive information.
  • CAN Controller Area Network
  • CANFD Controller Area Network
  • Ethernet registered trademark
  • ECU Electronic Control Unit
  • the communication device 3 communicates with the outside of the vehicle system 1 using a protocol such as wireless communication (for example, mobile phone communication, wireless LAN, WAN, C2X (Car to X: vehicle-to-vehicle or vehicle-to-infrastructure communication), or (Communication using GPS (Global Positioning System)) and acquiring / transmitting information on the outside world (for example, infrastructure, other vehicles, maps, etc.) or information about the vehicle (for example, information indicating the state of the vehicle) Conduct wireless communication, or have a diagnostic terminal (OBD), Ethernet (registered trademark) terminal, external recording medium (for example, USB memory, SD card, etc.) terminal, etc., and communicate with the first vehicle control system 2 Is.
  • a protocol such as wireless communication (for example, mobile phone communication, wireless LAN, WAN, C2X (Car to X: vehicle-to-vehicle or vehicle-to-infrastructure communication), or (Communication using GPS (Global Positioning System)) and acquiring
  • the second vehicle control system 4 is, for example, a vehicle control system configured by a network using a protocol different from the first vehicle control system 2 or the same protocol.
  • the drive device 5 drives a machine and an electric device (for example, an engine, a transmission, a wheel, a brake, a steering device, and the like) that control the vehicle motion in accordance with the control of the first vehicle control system 2, for example, an actuator or the like Is applicable.
  • an electric device for example, an engine, a transmission, a wheel, a brake, a steering device, and the like
  • the recognition device 6 obtains information input from the outside world and outputs information for generating information, and the outside world sensor such as a camera, radar, LIDAR, and ultrasonic sensor, and the state of the vehicle system 1 (motion state, Position information, acceleration, wheel speed, etc.).
  • the outside world sensor such as a camera, radar, LIDAR, and ultrasonic sensor, and the state of the vehicle system 1 (motion state, Position information, acceleration, wheel speed, etc.).
  • the output device 7 is wired or wirelessly connected to a network system (for example, the above-described in-vehicle network), receives data transmitted from the network system, and displays or outputs necessary information such as message information (for example, video and sound).
  • a network system for example, the above-described in-vehicle network
  • receives data transmitted from the network system and displays or outputs necessary information such as message information (for example, video and sound).
  • message information for example, video and sound.
  • a liquid crystal display, a warning light, a speaker, or the like is applicable.
  • the input device 8 is a device for generating an input signal for a user to input an operation intention or an instruction to the first vehicle control system 2, for example, a steering wheel, a pedal, a button, a lever, a touch panel, or the like.
  • the notification device 9 is a device for the vehicle system 1 to notify the outside world of the state of the vehicle and the like, for example, a lamp, an LED, a speaker, and the like.
  • FIG. 3 is a diagram illustrating an example of a physical architecture of the vehicle control system 2.
  • the physical architecture 20 can also be called an H / W (Hardware) configuration.
  • the physical architecture 20 includes, for example, a network link 301 and an ECU (Electronic Control Unit) 302.
  • ECU Electronic Control Unit
  • the network link 301 is a network link for connecting network devices on the in-vehicle network, and corresponds to a network link such as a CAN bus, for example.
  • the ECU 302 is connected to the network link 301 and a network link (including a dedicated line) other than the drive device 5 and the recognition device 6 and 301, and controls the drive device 5 and the recognition device 6, acquires information, and transmits and receives data to and from the network.
  • the ECU 302 is connected to a plurality of network links 301 and also serves as a gateway (hereinafter referred to as GW) that transmits and receives data to and from each network link.
  • GW gateway
  • a star type in which a plurality of ECUs are directly connected to the GW, or a series of links of the ECUs
  • a link type connected in a ring shape a mixed type in which each type is mixed and configured by a plurality of networks.
  • the ECU 302 performs control processing such as output of a control signal to the drive device 5, acquisition of information from the recognition device 6, output of the control signal and information to the network, and change of an internal state based on data received from the network. I do.
  • the ECU 302, the network link 301, and the processor in the ECU may also be referred to as physical elements below.
  • FIG. 4 is a diagram illustrating an internal configuration example of the ECU 302.
  • the ECU 302 includes, for example, a processor 401, an I / O (Input / Output) device 402, a timer 403, a ROM (Read Only Memory) 404, a RAM (Random Access Memory) 405, and an internal bus 406 as internal configurations. And comprising.
  • the processor 401 has a storage element such as a cache and a register, and executes control, and is composed of, for example, a CPU.
  • the processor 401 executes a logic function described later.
  • the I / O device 402 transmits and receives data to and from the network link 301 or the driving device 5 and / or the recognition device 6 connected by a network or a dedicated line.
  • the I / O device 402 can be configured by a communication I / F (Interface) device, for example.
  • the timer 403 manages time and time by using a clock (not shown).
  • the ROM 404 stores programs and nonvolatile data.
  • the RAM 405 stores programs and volatile data.
  • the internal bus 406 is a bus used for communication inside the ECU 302.
  • FIG. 5 is a diagram illustrating an example of parameters of the physical architecture 20.
  • FIG. 5A shows parameters assigned to physical elements (ECU and processor) of the physical architecture 20.
  • FIG. 5B shows parameters assigned to the network.
  • the physical element parameters include the calculation performance, the RAM amount, the ROM amount, the corresponding safety level, the cost, the multiplicity, the failure rate, and the diagnosis. Including rate and physical dependency.
  • the calculation performance MHz: processor performance
  • RAM amount KB: capacity
  • ROM amount KB: capacity
  • cost yen: price of ECU or processor
  • Corresponding safety level is a safety-related parameter and is information indicating a safety level that can be handled as hardware (ECU).
  • the corresponding safety level is defined by ISO26262, and for example, ASIL (Automotive Safety Level) or QM (Quality Management) is applicable.
  • the multiplicity is information indicating the number of systems that the ECU has. For example, when the ECU has a dual system and can cope with a single system failure, the multiplicity is 2 (the number of multiplicity).
  • the failure rate is information indicating the time (Failure in time) that a failure occurs once when a physical element (ECU or processor) continues to operate, and is used for safety verification.
  • the diagnostic rate indicates the diagnostic coverage of the function (for example, microcomputer diagnostic etc.) possessed by the physical element. This indicates that, for example, if the diagnostic rate is 99%, 99% of failures can be dealt with, but the remaining 1% cannot be dealt with. It may be known at the time of design which failure cannot be handled.
  • the physical dependency is information indicating which hardware the corresponding physical element depends on (for example, when the ECU is connected to the same power source as another ECU).
  • a parameter is assigned to either the ECU or the processor at the time of verification, and either parameter is set. use.
  • a parameter that outputs a worse result for example, a low value as ASIL
  • ASIL a parameter that outputs a worse result
  • failure rate and the diagnosis rate are described as examples of the same parameter for all failure modes, but may be different parameters for each failure mode of each element.
  • the network has parameters of communication speed (bps), cost (yen: network cable price), and multiplicity (communication line redundancy).
  • FIG. 6 is a diagram illustrating a configuration example of the logical architecture 601 of the vehicle control system (for example, the first vehicle control system 2).
  • the logical architecture 601 of the vehicle control system includes, for example, an integrated recognition unit 602, an automatic driving control unit 603, a user input unit 604, an output management unit 605, a notification management unit 606, an abnormality detection unit 607, and a switching unit. 608, a motion control unit 609, and a safety control unit 610.
  • the integrated recognition unit 602 executes processing for creating an external recognition map in which external recognition information transmitted from the plurality of recognition devices 6 and the communication device 3 is integrated.
  • the automatic driving control unit 603 generates automatic driving control information (such as a trajectory) based on the external world recognition map generated by the integrated recognition unit 602 and the user input input from the user input unit 604, and the abnormality detection unit 607. And to the switching unit 608.
  • the automatic operation control unit 603 issues an output instruction to the output management unit 605 and issues a notification instruction to the notification management unit 606.
  • the output management unit 605 gives an output instruction to the output device 7 in accordance with the outputs of the automatic operation control unit 603 and the abnormality detection unit 607.
  • the notification management unit 606 gives a notification instruction to the notification device 9 according to the outputs of the automatic operation control unit 603 and the abnormality detection unit 607.
  • the user input unit 604 generates user instruction information in accordance with the input from the input device 8.
  • the abnormality detection unit 607 detects an abnormality based on the automatic operation control information from the automatic operation control unit 603 or the like, or predetermined information from each unit (not shown), and displays the abnormality detection result as a switching unit 608, a safety control unit 610, and an output management unit. 605 and the notification management unit 606.
  • the switching unit 608 switches the output to the motion control unit 609 to the input from the automatic operation control unit 603, the input from the user input unit 604, or the input of the safety control unit 610 based on the abnormality detection result of the abnormality detection unit 607 and the like.
  • an abnormality control system safety control
  • a normal control system also referred to as a main control system: 602 ⁇ 603 ⁇ 608 ⁇ 609 from the automatic operation control unit 603.
  • a system 602 ⁇ 610 ⁇ 608 ⁇ 609.
  • the motion control unit 609 controls the plurality of drive devices 5 according to the trajectory information or the motion control information provided from the switching unit 608, the state of the vehicle system 1 acquired from the recognition device 6, and the response from the drive device 5. I do.
  • the safety control unit 610 performs control when a notification of abnormality detection is received.
  • the safety control unit 610 has a degeneration function of the automatic driving control unit 603, and is configured to be able to alternatively execute a part of the functions of the automatic driving control unit 603 in an emergency (at the time of detecting an abnormality). .
  • a function that performs main control during normal operation is called a main function
  • a function that performs main control after detection of an abnormality and occurrence of an abnormality is called a safety function.
  • the main functions correspond to the integrated recognition unit 602, the automatic operation control unit 603, the user input unit 604, the output management unit 605, the notification management unit 606, and the exercise control unit 609. Further, the abnormality detection unit 607, the switching unit 608, and the safety control unit 610 correspond to the safety function.
  • FIG. 7 is a diagram illustrating an example of parameters of the logical architecture 601.
  • FIG. 7A shows parameters assigned to the main function.
  • FIG. 7B shows parameters assigned to the safety function.
  • FIG. 7C shows parameters for the logical connection.
  • the main function parameters include a logical function type, a calculation amount, a consumption RAM, and a consumption ROM.
  • the type of the logical function is information indicating the type of the logical function, and is used for determining the main function / safety function.
  • “main function” is input.
  • the calculation amount (MHz) is information indicating the performance of the ECU or the processor required for executing the corresponding function.
  • the consumption RAM (KB) is information indicating the amount of consumption of RAM required for executing the corresponding function.
  • the consumption ROM (KB) is information indicating the amount of ROM consumption required for executing the corresponding function. The calculation amount, the consumption RAM, and the consumption ROM are mainly used when the architecture is quantitatively evaluated.
  • Safety function parameters include logical function type, safety function type, safety control mode, calculation amount, consumption RAM, consumption ROM, required safety level, and detection target. , Detection failure modes, detection rates, and independence requirements.
  • the logic function type is information indicating the type of the logic function, and is used for determining the main function / safety function.
  • safety function is input.
  • the calculation amount (MHz) is information indicating the performance of the ECU or the processor required for executing the corresponding function.
  • the consumption RAM (KB) is information indicating the amount of consumption of RAM required for executing the corresponding function.
  • the consumption ROM (KB) is information indicating the amount of ROM consumption required for executing the corresponding function.
  • the calculation amount, consumption RAM, and consumption ROM are mainly used when performing quantitative evaluation of the architecture.
  • the type of logical function, the amount of calculation, the consumption RAM, and the consumption ROM are used when the reputation evaluation of the architecture is performed in the same manner as the main function.
  • the type of safety function is information indicating the type of the corresponding safety function, and is used for determination of safety function cooperation described later.
  • the type of the safety function indicates which function of detection, control, and switching is applicable.
  • the safety control mode is information indicating what content is required for the safety control to be realized by the corresponding safety function. For example, information such as function stop and function continuation is given.
  • the safety control mode also includes required multiplicity information.
  • Requirement safety level is information indicating the safety level required for the corresponding safety function. For example, QM and ASIL are assigned, and execution of a safety function with a corresponding safety level is required on the physical architecture.
  • the detection target is information indicating a logical function that is a target for which the corresponding safety function should detect an event (for example, an abnormality).
  • the detection target is the integrated recognition unit 602 and the automatic operation control unit 603.
  • the detected failure mode indicates which failure mode the corresponding logical function corresponds to among the plurality of failure modes (for example, stop at the time of failure, false value output at the time of failure, output of the value at the time of failure, etc.) Information.
  • the detection rate is information indicating how many faults and errors can be detected in the corresponding safety function, like the “diagnosis rate” of the physical element. For example, when the detection rate is 99%, it means that 99% failure / error can be detected, but the remaining 1% failure / error cannot be detected.
  • the independence request is information indicating a logical function name that should not fail at the same time when a failure occurs for the corresponding safety function.
  • the independence requirement is a parameter for preventing a design such as a common cause failure and a subordinate failure in which, for example, the safety function and the main function fail at the same time, and as a result, safety control becomes impossible.
  • the parameters for logical connection include the traffic of the corresponding communication path.
  • the amount of communication is used when quantitatively evaluating the architecture.
  • NG is output at the time of safety verification when parameters such as a detection target, a detection failure mode, and a detection rate are not given even though the type of the safety function is “detection”.
  • FIG. 8 is a diagram illustrating a configuration example when the logical architecture is arranged in the physical architecture.
  • the function placement unit 101 places the given logical architecture 601 (see FIG. 6) on the given physical architecture 20 (see FIG. 3). As a result, processing of which logical function is executed on which physical element (ECU, microcomputer) and what content is implemented for communication on the network is determined.
  • logic functions that are strongly related to each other are arranged in the same ECU.
  • the integrated recognition unit 602 and the automatic operation control unit 603, and the user input unit 604 and the output management unit 605, which are main functions, are arranged in the same ECU.
  • An abnormality detection unit 607 and a safety control unit 610 that are safety functions are arranged in the same ECU.
  • a switching unit 608 that is a safety function and a motion control unit 609 that is a main function are arranged in the same ECU.
  • FIG. 9 is a diagram illustrating an example of FTA (Fault Tree Analysis) that can be used as safety analysis information.
  • the FTA 900 represents a tree-like structure, and includes a top event (top event) 901, an event 903 serving as each leaf, and a branch gate 902.
  • the top event (the event at the top of the tree) is a hazard event (dangerous event), and is linked to lower events by AND and OR gates, and decomposed into lower events that cause the top event.
  • the OR gate means that an upper event occurs when either event occurs
  • the AND gate means that an upper event occurs only when both events occur. In this way, it is possible to clarify the relationship between events that generate the highest hazard.
  • FIG. 10 is a diagram illustrating an example of parameters assigned to each event and each gate.
  • FIG. 10A shows parameters to be assigned to each event.
  • FIG. 10B shows parameters given to each gate.
  • Event parameters are the event (higher event) or gate (higher gate) located above the corresponding event, the event type (intermediate event or basic event), the failure function, and the failure mode. And as constituent items.
  • the content of the event is represented by a combination of the failure function and the failure mode.
  • the failure function and failure mode are described not only in the basic event but also in the intermediate event. By doing so, for example, not only component failures but also system level failures can be described.
  • a table (not shown) indicating the contents of the logic function is prepared separately, and the contents of each logic function can be grasped by referring to the table.
  • the gate parameters have an event or gate positioned above each gate and a gate type (OR or AND) as configuration items.
  • FIG. 11 is a flowchart for explaining an overview of the safety verification processing according to the first embodiment.
  • the processing outline will be described with the safety verification unit 102 as a program as the operating subject.
  • the program is read and executed by the processor of the vehicle control system verification device 100, the safety verification unit 102 is It can also be read as “processor”.
  • Step 1101 the safety verification unit 102 executes a safety requirement verification process on the architecture after the function arrangement. Details of the safety requirement verification process will be described later (see FIG. 12).
  • Step 1102 If the verification result of the safety requirement is OK (Yes in S1102), the safety verification unit 102 moves the process to Step 1103, and if the verification result of the safety requirement is NG (No in S1102), the safety verification unit 102 To step 1104.
  • Step 1103 The safety verification unit 102 outputs OK as the safety verification result and ends the process.
  • Step 1104 The safety verification unit 102 outputs an NG result and its reason and which safety requirement was verified as NG. In this way, safety requirements are verified.
  • FIG. 12 is a flowchart for explaining the details of the safety requirement verification process (step 1102).
  • Step 1201 In the safety requirement verification process, the safety verification unit 102 repeats the processing from step 1202 to step 1205 for all events of the safety analysis information 900.
  • Step 1202 The safety verification unit 102 checks for each event whether the corresponding safety function exists on the architecture. Specifically, whether the parameter of the failure function (for example, logical function 1 in FIG. 10) of the corresponding event (for example, ET3) exists in the detected failure mode and the detection target in the corresponding safety function. Checked. If there is a corresponding safety function (Yes in step 1202), the process proceeds to step 1203. If there is no corresponding safety function (No in step 1202), the process proceeds to step 1205.
  • the parameter of the failure function for example, logical function 1 in FIG. 10
  • ET3 for example, ET3
  • the process proceeds to step 1203. If there is no corresponding safety function (No in step 1202), the process proceeds to step 1205.
  • Step 1203 The safety verification unit 102 determines whether the safety level and multiplicity requirements are satisfied at the location of the corresponding safety function in the physical architecture 20.
  • the safety level if the value of the required safety level, which is a parameter of the corresponding safety function, is smaller than or equal to the corresponding safety level of the physical element at the placement destination, it is determined as OK. Specifically, when the required safety level of the safety function is ASIL-C, it is determined to be OK when the corresponding safety level of the physical element at the placement destination is ASIL-C or higher (ASIL-D or the like).
  • multiplicity when the required multiplicity value included in the safety control mode, which is a parameter of the corresponding safety function, is smaller than or equal to the multiplicity of the physical element at the placement destination, it is determined as OK. Specifically, when the required multiplicity of the safety function is 2, it is determined as OK when the multiplicity of the arrangement-destination physical element is 2 or more.
  • step 1203 If the placement destination safety level and multiplicity are OK (Yes in step 1203), the process proceeds to step 1204. If the safety level and multiplicity of the placement destination are NG (in the case of no in step 1203), the processing moves to step 1205.
  • Step 1204 The safety verification unit 102 sets the content of the corresponding event as OK.
  • Step 1205 The safety verification unit 102 sets the content of the corresponding event as NG.
  • Step 1206 The safety verification unit 102 processes the next event. After the processing is completed for all events, the processing moves to step 1207.
  • the safety verification unit 102 determines the safety requirement verification by applying the processing results of steps 1201 to 1206 to the FTA tree. Specifically, for each FTA event, the safety verification unit 102 inputs OK and NG results of each event to the FTA, and performs determination according to the FTA tree. That is, OK and NG are traced upward from each event, and the determination at each gate is determined as AND and OR to determine whether the highest event occurs.
  • the safety verification unit 102 determines NG as T (True), OK as F (False), and makes a determination based on AND conditions and OR conditions, and returns OK when the top event (top event) is False. In the case of True, NG is returned. In this way, the overall safety requirements are verified.
  • the vehicle control system verification device 100 can present the safety requirements that are incomplete to the user.
  • step 1203 only the safety degree may be determined in the placement destination verification process.
  • the multiplicity can be omitted in step 1203 because it is also performed in the verification of safety function cooperation. Thereby, the amount of calculation can be reduced.
  • step 1207 if the determination in the FTA tree is not performed and there is NG in any event, the safety requirement verification is determined as NG based on the result, and the safety requirement verification process is terminated. Also good. By determining that the safety function should correspond to all safety requirements, it is possible to shorten the processing time without performing the FTA tree calculation.
  • the architecture quantitative evaluation unit 103 performs quantitative evaluation of the architecture in which the function verification has been performed and the safety verification result is determined to be OK.
  • the quantitative evaluation can be realized, for example, by calculating the usage rate of the logical function on the physical element, calculating the communication occupation rate, and calculating the cost of the physical element.
  • the usage rate of the logical function on the physical element is calculated by calculating the total value for each of the calculation amount, the consumption RAM, and the consumption ROM for the plurality of logical functions arranged in the physical element of the physical architecture 20. It can be calculated by calculating the usage rate.
  • the communication occupancy rate can be calculated by adding the communication usage amounts by the respective logical functions on the network and calculating the occupancy rate.
  • the cost of the physical element can be calculated by adding up the costs for the physical elements used in the entire physical architecture, that is, the physical elements in which one or more logical functions are arranged.
  • the second embodiment discloses another form of verification and evaluation based on a quantitative evaluation of safety. Specifically, safety requirement verification in the first embodiment (step 1101), or another form of processing (safety quantitative evaluation processing: referred to as top event occurrence probability calculation processing) executed in the above-described architectural quantitative evaluation. Is also possible).
  • safety quantitative evaluation processing referred to as top event occurrence probability calculation processing
  • FIG. 13 is a diagram showing an outline of the safety quantitative evaluation process according to the second embodiment. This process corresponds to a process for calculating the probability that a top event will occur.
  • One of a plurality of events constituting the FTA is selected, and the detection target of the logical function corresponding to the event (see FIG. 7) and the failure function and failure mode of the logical function corresponding to the event (see FIG. 10) are selected.
  • the main function and the safety function are specified.
  • the failure rate of the physical element corresponding to the identified main function (see FIG. 5) and the detection rate of the safety function that detects the failure of the main function (see FIG. 7) are acquired.
  • the residual failure rate (the proportion of failures that cannot be detected) is calculated from the acquired failure rate and detection rate.
  • the residual failure rate of each event is integrated according to the tree conditions, and the occurrence probability of the top event is calculated.
  • FIG. 14 is a flowchart for explaining details of the safety quantitative evaluation processing according to the second embodiment.
  • the architecture quantitative evaluation unit 103 calculates the occurrence probability (residual failure rate) of the corresponding hazard (top event) according to the following procedure.
  • the processing contents will be described with the architecture quantitative evaluation unit 103 as a program as the operation subject.
  • the architecture quantitative evaluation unit 103 is It can also be read as “processor”.
  • Steps 1401 and 1406 The architecture quantitative evaluation unit 103 repeats the processing from step 1402 to step 1405 for all events of the safety analysis information (FTA).
  • FTA safety analysis information
  • Step 1402 The architecture quantitative evaluation unit 103 searches the corresponding main function and safety function for the event to be processed.
  • the main function the logical function (main function) that is the target of detection (in other words, monitoring) is described in the detection target of the logical function (safety function) corresponding to the event, so this information is extracted.
  • Main function A in the example of FIG. 13
  • safety function A the corresponding safety function (here, safety function A) is identified from the failure function and failure mode (see FIG. 10) of the event to be processed.
  • the architecture quantitative evaluation unit 103 is a failure rate corresponding to the corresponding failure mode, and the failure rate (see FIG. 5) described in the parameter of the ECU or microcomputer (ECU 2 in this case) in which the main function A is arranged. get.
  • Step 1404 The architecture quantitative evaluation unit 103 acquires the detection rate of the searched safety function (safety function A) from the parameter of the safety function (see FIG. 7).
  • Step 1407 After calculating the residual failure rate of all events, the architecture quantitative evaluation unit 103 calculates the occurrence probability of the top event according to the structure of the FTA tree. Here, after calculating the residual failure rate of each event, the occurrence probability of the top event is calculated according to the operation of the AND or OR gate. Also, here, all events are considered to be independent, the OR gate adds the residual failure rate of each event, and the AND gate calculates the occurrence rate of the upper event by multiplying the residual failure rate of each event. . In this way, a quantitative evaluation of safety is performed.
  • the residual failure rate of the hazard is compared with a required value for each hazard (for example, 10 FIT in ASIL-D). Since it is less than the value, it is determined that the verification is OK.
  • the third embodiment discloses executing a process for verifying safety function cooperation (safety function cooperation verification process) in the safety verification process.
  • the difference from the first embodiment is that a safety function linkage verification process is further executed in the safety verification process of FIG.
  • the safety verification process according to the third embodiment will be described.
  • FIG. 15 is a flowchart for explaining an overview of the safety verification process according to the third embodiment. As shown in FIG. 15, step 1501 and step 1502 are added to the safety verification processing (FIG. 11: step 1101 to step 1104) according to the first embodiment. Only the added processing will be described below.
  • Step 1501 The safety verification unit 102 verifies the cooperation of safety functions in the physical architecture after the logical functions are arranged. Details of this processing will be described later (see FIG. 16).
  • Step 1502 The safety verification unit 102 determines whether or not the verification result of the safety function cooperation is OK as a result of the processing in step 1501. If the desired safety function cooperation is performed (Yes in step 1502), the process proceeds to step 1103. If the desired safety function linkage is not performed (No in step 1502), the process proceeds to step 1104.
  • FIG. 16 is a flowchart for explaining details of the safety function cooperation verification process (step 1501).
  • the safety function cooperation verification process will be described with the safety verification unit 102 as a program as the operating subject. However, since the program is read and executed by the processor of the vehicle control system verification device 100, the safety verification is performed.
  • the unit 102 may be read as “processor”.
  • Step 1601 Since the safety function linkage verification process is executed for all safety functions of the logical architecture, the safety verification unit 102 first acquires the safety control mode from the parameters of the corresponding safety function.
  • the safety control mode includes function continuation, safety stop, etc., and the information is acquired corresponding to the corresponding safety function.
  • FIG. 17 is a diagram illustrating an example of a safety control model.
  • FIG. 17A shows an example of a safety control model corresponding to “safe stop” in the safety control mode.
  • FIG. 17B shows an example of a safety control model corresponding to “function continuation” in the safety control mode.
  • S indicates a sensor
  • A indicates an actuator.
  • the safety function (safety function A) having the “detection” function as the parameter safety function type (see FIG. 7) is the parameter detection target (see FIG. 7).
  • the output of the main function C is input to a safety function (safety function B) having a “switching” function of the safety function type (see FIG. 7).
  • the safety function (safety function A) having the “detection” function with the parameter safety function type (see FIG. 7) is the parameter detection target (see FIG. 7). It is the same in that it is connected to the main functions A, B, and C specified by.
  • a safety function that performs control for “function continuation” is required, and the output of the detection result is a safety function type (see FIG. 7) and a safety function having a “control” function.
  • (Safety function C) is input.
  • the safety function C also has an input (S) for performing “control”.
  • safety function C the safety function
  • safety function B the safety function that performs “switching”.
  • Such cooperation is required when “function continuation” is specified in the safety control mode, so the safety verification unit 102 checks whether such cooperation is established on the logical architecture. .
  • Step 1603 The safety verification unit 102 determines whether the check result of the safety function cooperation in step 1602 is OK. If the check result is NG (NO in step 1603), the process proceeds to step 1604. If the check result is OK (YES in step 1603), the process proceeds to step 1605.
  • Step 1604 If the result of the logical function check is NG in step 1603, the safety verification unit 102 outputs that the check result of the corresponding safety requirement is NG and the reason. In this case, the safety requirements for the logical function check NG and the information on the cooperation of the logical functions that are lacking there are output.
  • the safety verification unit 102 When the safety requirement check result is NG in step 1606, the safety verification unit 102 outputs the NG result and the NG reason. In this case, the safety requirement and the information on the route that are insufficient in safety level and / or multiplicity are output as the NG reason.
  • Step 1605 The safety verification unit 102 checks the safety requirements of the placement destination and the route for the cooperation of the safety function confirmed in Step 1603.
  • FIG. 18 is a diagram showing an example of checking the safety requirements of the placement destination and the route related to the cooperation of the safety functions.
  • FIG. 18A shows an example in which the safety function A and the safety function B are linked, and the request for the safety level of the function is ASIL-D.
  • FIG. 18B shows an evaluation example when function continuation is specified as a safety function safety control mode.
  • the safety verification unit 102 checks whether or not the placement destination ECUs 1 and 3 and the intermediate NW (network) 1, ECU 2, and NW2 also satisfy the required safety level (ASIL-D). To do. The multiplicity is confirmed in the same manner. In this way, the safety requirements at the time of function cooperation are checked.
  • ASIL-D required safety level
  • each function is arranged as shown in FIG. 18B.
  • the safety degree is determined as in the case of FIG. 18A.
  • a function for “function continuation” is added.
  • function continuation independent and redundant paths are required for the main function and the safety function. This is because when the route by the main function cannot be used due to a failure or the like, it is necessary to realize a function similar to the main function that has failed by another route. Therefore, the safety verification unit 102 searches for another independent route by a route search algorithm.
  • Step 1606 The safety verification unit 102 determines whether or not the safety requirement check result of the safety function cooperation obtained in step 1605 is OK. If the safety requirement check result is NG (NO in step 1606), the process proceeds to step 1604. If the safety requirement check result is OK (YES in step 1606), the process proceeds to step 1607.
  • Step 1607 The safety verification unit 102 outputs an OK result (the result of the safety requirement check for safety function cooperation is OK).
  • the fourth embodiment discloses a configuration for executing safety verification of a vehicle control system within the vehicle control system.
  • FIG. 19 is a diagram illustrating an example of a configuration (physical architecture) of a vehicle control system according to the fourth embodiment.
  • the vehicle control system verification device 100 shown in FIG. 1 is arranged in the ECU 302, and a safety verification process is executed in the vehicle control system based on a given FTA.
  • the safety verification process is mainly executed at the time of design.
  • the vehicle control system verification device 100 since the vehicle control system verification device 100 is mounted in the vehicle control system, for example, The safety verification process can be executed when the control program is rewritten.
  • the vehicle control system verification apparatus 100 collects architecture information through the network link 301.
  • FIG. 20 is a diagram illustrating an example of the architecture configuration information received by the vehicle control system verification apparatus 100 in the fourth embodiment.
  • FIG. 20A shows physical architecture configuration information.
  • FIG. 20B shows logical architecture configuration information.
  • the physical architecture configuration information includes each physical element name (ECU, microcomputer), a network name connected to the corresponding physical element, and various parameters of the physical element (see FIG. 5) as configuration items. Contains.
  • the physical architecture information is constructed by the vehicle control system verification device 100 collecting information owned by each from a plurality of ECUs.
  • the logical architecture configuration information includes, as configuration items, each logical function name (ID), a physical element name (arrangement location), and a logical architecture parameter (see FIG. 7). .
  • the logical architecture information is also constructed by the vehicle control system verification device 100 collecting information owned by each from a plurality of ECUs.
  • Vehicle control system verification device 100 collects safety analysis information held in advance in ECU 302 and network link 301 in addition to physical architecture configuration information and logical architecture information. Then, the vehicle control system verification apparatus 100 executes vehicle control system verification and safety verification processing, and outputs a verification result to a network or the like. Thereby, it becomes possible to always verify the safety of the state of the vehicle control system.
  • the vehicle control system verification device of the present disclosure has a logical function (safety function) corresponding to the safety analysis result based on the information on the safety analysis result provided. Verify whether or not. By doing so, it becomes possible to comprehensively (not partially) verify the safety of the architecture of the vehicle control system.
  • the logical architecture may be constructed based on information on a safety analysis result (FTA). As a result, it is possible to verify whether the architecture set to satisfy the requirements of the safety analysis result can really cope with the safety analysis result. Further, the vehicle control system verification device verifies whether or not the physical architecture in which the logical architecture is arranged satisfies the safety level and the multiplicity required by the logical architecture.
  • the safety on the logical architecture can be verified, but also the safety on the physical architecture can be verified.
  • the safety analysis result is FTA
  • a top event occurs when the result of logical architecture safety verification corresponding to a plurality of events in FTA and the result of physical architecture safety verification are applied to FTA.
  • the vehicle control system verification device of the present disclosure quantitatively evaluates a physical architecture (for example, including a plurality of physical elements and a network).
  • the physical architecture can be quantitatively evaluated by calculating a usage rate of a plurality of physical elements and a network occupation rate when the logical architecture is arranged in the physical element.
  • the vehicle control system verification device provides, for each of a plurality of FTA events, the residual failure rate of the logical function of the logical architecture corresponding to each event in the logical architecture. It calculates from the failure rate and detection rate that are parameters of the logical function, and applies the residual failure rate of the logical function corresponding to each event to the FTA to calculate the residual failure rate of the top event. By doing so, it is possible to provide a probability that a top event (for example, a dangerous failure) will occur even if the safety function is appropriate. Based on this result, it is possible to consider whether further architecture improvements (lowering the failure rate or increasing the detection rate) are necessary.
  • the vehicle control system verification device of the present disclosure checks whether or not each logical function operates in cooperation with the safety control mode indicating the control content to be realized by the logical architecture when an abnormality occurs. For example, when the safety control mode is a safety stop, whether or not the safety function having a function for detecting an abnormality, the main function to be detected for an abnormality, and the safety function having a switching function operate in cooperation. Is checked. In addition, when the safety control mode is function continuation, it has a safety function having a function for detecting an abnormality, a main function to be detected for an abnormality, a safety function having a function for performing alternative control, and a switching function. It is checked whether the safety function operates in cooperation. By doing so, it becomes possible to verify the cooperation of the safety functions in the architecture. In addition, it becomes possible to verify the function linkage according to the type of each safety control mode.
  • the vehicle control system verification device of the present disclosure can be arranged in the physical architecture of the vehicle control system.
  • the vehicle control system verification device acquires information on the logical architecture and physical architecture of the vehicle control system and information on the safety analysis result input from the outside, and verifies the safety of the architecture based on these. For example, a logical architecture is verified whether it has a logical function (safety function) corresponding to a safety analysis result (FTA).
  • FTA safety analysis result
  • the physical architecture is also verified to meet the required safety and multiplicity requirements. In this way, the vehicle is included in the vehicle control system.
  • control system verification device By mounting the control system verification device, for example, even when the control program is rewritten, the safety of the vehicle control system can be verified.
  • the embodiment of the present disclosure can also be realized by a program code of software that realizes the function.
  • a storage medium in which the program code is recorded is provided to the system or apparatus, and the computer (or CPU or MPU) of the system or apparatus reads the program code stored in the storage medium.
  • the program code itself read from the storage medium realizes the functions of the above-described embodiments, and the program code itself and the storage medium storing the program code constitute the present invention.
  • a storage medium for supplying such program code for example, a flexible disk, CD-ROM, DVD-ROM, hard disk, optical disk, magneto-optical disk, CD-R, magnetic tape, nonvolatile memory card, ROM Etc. are used.
  • an OS operating system
  • the computer CPU or the like performs part or all of the actual processing based on the instruction of the program code.
  • the program code is stored in a storage means such as a hard disk or a memory of a system or apparatus, or a storage medium such as a CD-RW or CD-R
  • the computer (or CPU or MPU) of the system or apparatus may read and execute the program code stored in the storage means or the storage medium when used.
  • control lines and information lines are those that are considered necessary for the explanation, and not all control lines and information lines on the product are necessarily shown. All the components may be connected to each other.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Automation & Control Theory (AREA)
  • Computer Hardware Design (AREA)
  • Mechanical Engineering (AREA)
  • Transportation (AREA)
  • Quality & Reliability (AREA)
  • Human Computer Interaction (AREA)
  • Evolutionary Computation (AREA)
  • Geometry (AREA)
  • Debugging And Monitoring (AREA)
  • Valves And Accessory Devices For Braking Systems (AREA)
  • Safety Devices In Control Systems (AREA)
  • Traffic Control Systems (AREA)
  • Testing And Monitoring For Control Systems (AREA)

Abstract

本発明は、安全分析結果に基づき、機能の設計の安全性を網羅的に検証するための技術を提供する。本開示による車両制御システム検証装置は、車両制御システムの論理アーキテクチャの安全性を検証するためのプログラムを格納する記憶デバイスと、記憶デバイスからプログラムを読み込み、論理アーキテクチャの安全性を検証するプロセッサと、を備える。当該プロセッサは、与えられる安全分析結果の情報に基づいて、論理アーキテクチャが安全分析結果に対応する論理機能を有するか否かを検証する処理を実行する。

Description

車両制御システム検証装置、車両制御システム、及び車両制御システム検証方法
　本開示は、車両制御システム検証装置、車両制御システム、及び車両制御システム検証方法に関する。
　近年、自動車の電子制御は急速に複雑化してきており、その対応が緊急課題であり、より信頼性のある車両制御システムが望まれている。このような車両制御システムを実現するためには、車両制御システムで実装される各機能の信頼性を検査できるようにすることが望ましい。
　例えば、特許文献１は、要求されるシステムの機能を検査するための信頼性機能を用いて、そのために必要とされる、システムのハードウェアコンポーネントに基づいて、ソフトウェアベースの電子システムの安全性と信頼性を検査することを開示している。また、特許文献２は、安全性重視システムの設計とベリファイのための改良された方法について開示している。特許文献１或いは２によれば、安全性や信頼性に関連する要件に対し、アーキテクチャの設計、インプリメンテーションの内容を検査・検証することができる。
特表２００７－５０６５９１号公報 特表２００７－５２８５３２号公報
　しかしながら、特許文献１及び２には、安全分析結果（安全分析情報ともいう）から網羅的に安全機能の要件を検証することや、信頼性における多重度（多重度については特許文献１に記載されている）以外に安全機能同士の関係性を検証することについては開示されていない。従って、特許文献１及び２に開示の技術では、車両制御システムの各機能を検証する上で十分ではない。
　本開示はこのような状況に鑑みてなされたものであり、安全分析結果に基づき、機能の設計の安全性を網羅的に検証するための技術を提供するものである。
　上記課題を解決するために、本開示の一実施の態様として、例えば特許請求の範囲に記載されている技術的思想を用いればよい。具体的には、本開示による車両制御システム検証装置は、車両制御システムの論理アーキテクチャの安全性を検証するためのプログラムを格納する記憶デバイスと、記憶デバイスからプログラムを読み込み、論理アーキテクチャの安全性を検証するプロセッサと、を備える。当該プロセッサは、与えられる安全分析結果の情報に基づいて、論理アーキテクチャが安全分析結果に対応する論理機能を有するか否かを検証する処理を実行する。
　本開示に関連する更なる特徴は、本明細書の記述、添付図面から明らかになるものである。また、本開示の態様は、要素及び多様な要素の組み合わせ及び以降の詳細な記述と添付される特許請求の範囲の様態により達成され実現される。
　本明細書の記述は典型的な例示に過ぎず、本開示の特許請求の範囲又は適用例を如何なる意味に於いても限定するものではないことを理解する必要がある。
　本開示によれば、自動運転システムの論理アーキテクチャおよび物理アーキテクチャと機能配置情報に基づく設計について、安全分析情報に基づき網羅的に検証を行うことが可能となる。
本開示の実施形態による車両制御システム検証装置１００の概略構成を示す図である。 評価対象の車両制御システムを備える車両システム１の概略構成例を示す図である。 車両制御システム２の物理アーキテクチャの例を示す図である。 ＥＣＵ３０２の内部構成例を示す図である。 物理アーキテクチャ２０のパラメータ例を示す図である。 車両制御システム（例えば、第１の車両制御システム２）の論理アーキテクチャ６０１の構成例を示す図である。 論理アーキテクチャ６０１のパラメータ例を示す図である。 論理アーキテクチャが物理アーキテクチャに配置された場合の構成例を示す図である。 安全分析情報として用いることができるＦＴＡ（Fault Tree Analysis）の例を示す図である。 ＦＴＡの各イベントおよび各ゲートに付与するパラメータの例を示す図である。 第１の実施形態による安全性検証処理の概要を説明するためのフローチャートである。 安全要件検証処理（ステップ１１０２）の詳細を説明するためのフローチャートである。 第２の実施形態による安全性定量評価処理の概要を示す図である。 第２の実施形態による安全性定量評価処理の詳細を説明するためのフローチャートである。 第３の実施形態による安全性検証処理の概要を説明するためのフローチャートである。 安全機能連携検証処理（ステップ１５０１）の詳細を説明するためのフローチャートである。 安全制御モデルの例を示す図である。 安全機能の連携に関する配置先と経路の安全要件のチェック例を示す図である。 第４の実施形態による車両制御システムの構成（物理アーキテクチャ）例を示す図である。 第４の実施形態において車両制御システム検証装置１００が受信するアーキテクチャ構成情報の例を示す図である。
　本開示の実施形態による車両制御システム検証装置は、与えられる安全分析結果に基づいて、機能の設計の安全性及び配置の適切さを網羅的に検証し、必要な要件を充足しているか否か、安全機能間の連携の有無について検証するものである。具体的には、本開示による車両制御システム検証装置は、与えられる安全分析結果（ＦＴＡ）の情報に基づいて、車両制御システムの論理アーキテクチャが安全分析結果に対応する論理機能を有するか否かを検証する。なお、論理アーキテクチャは、安全分析結果の情報に基づいて構築しても良い。設計時の安全機能の検証は、ＦＴＡの安全性の要件を満足するようにアーキテクチャを設計し、それが実際にターゲットとなるＦＴＡの安全性の要件を満足するか否かチェックするものだからである。
　また、車両制御システム検証装置は、車両制御システムの物理アーキテクチャが論理アーキテクチャで要求される安全度及び多重度を満足するか否かを検証する。
　以下、本発明に好適な実施形態について、より詳細に説明する。なお、実施形態では、主に車両制御システムの検証装置について説明しており、車両制御システムの検証に好適であるが、それ以外のシステムに対しての適用を妨げるものではない。
（１）第１の実施形態
　第１の実施形態は、車両制御システムの論理アーキテクチャにおいてＦＴＡで必要とされる安全機能が存在するか、及び車両制御システムの物理アーキテクチャ上に論理アーキテクチャを配置したときに物理アーキテクチャが要求される安全度と多重度を満足するかについて検証することについて開示する。
　＜車両制御システム検証装置＞
　図１は、本開示の実施形態による車両制御システム検証装置１００の概略構成を示す図である。
　車両制御システム検証装置１００は、機能配置部１０１と、安全性検証部１０２と、アーキテクチャ定量評価部１０３と、を備える。
　機能配置部１０１は、例えば、論理アーキテクチャ６０１と物理アーキテクチャ２０とを入力とし、機能配置の例（図８参照）のように論理アーキテクチャ６０１を物理アーキテクチャ２０上に配置する処理を実行する。
　安全性検証部１０２は、機能配置後のアーキテクチャと安全分析情報（例えばＦＴＡ：Fault Tree Analysis（図９参照））９００を入力とし、本開示で提案される安全性検証のフローに従って設計されたアーキテクチャの安全性の検証を行う。そして、安全性検証部１０２は、検証結果として、安全性検証ＯＫ、或いは安全性検証ＮＧ及びその理由を機能配置部１０１に出力する。なお、検証結果は、アーキテクチャ定量評価部１０３に直接出力されるようにしても良い。
　アーキテクチャ定量評価部１０３は、アーキテクチャの安全性の検証結果を受け、主に安全性検証がＯＫのアーキテクチャについて定量評価を行い、評価結果を出力する。
　以上のようにして、車両制御システム検証装置１００は、車両制御システムの検証および評価を実行する。
　なお、車両制御システム検証装置１００は、プロセッサ（ＣＰＵなど）やメモリ（ＲＯＭやＲＡＭなど）などを有するコンピュータによって実現することができる。この場合、機能配置部１０１、安全性検証部１０２、及びアーキテクチャ定量評価部１０３はプログラムによって構成され、プロセッサがプログラムメモリ（ＲＯＭ）から各種プログラムを読み込み、実行するように構成される。
　論理アーキテクチャ６０１、物理アーキテクチャ２０、機能配置部１０１、及び安全性検証部１０２の詳細については後述する。
　＜車両制御システムの構成＞
　図２は、評価対象の車両制御システムを備える車両システム１の概略構成例を示す図である。車両システム１は、自動車などが該当し、内部に車両制御システムを有している。
　車両システム１は、例えば、第１の車両制御システム２と、少なくとも１つの通信装置３と、第２の車両制御システム４と、少なくとも１つの駆動装置５と、少なくとも１つの認識装置６と、出力装置７と、入力装置８と、通知装置９と、を備えている。ここでは、例として２つの車両制御システム（第１の車両制御システム２及び第２の車両制御システム４）を挙げたが、２つに限られるものではない。また、複数の車両制御システムが連携して動作するような構成を採用しても良い。
　第１の車両制御システム２は、例えば車載ネットワーク（ＣＡＮ：Controller Area Network、ＣＡＮＦＤ：CAN with Flexible Data-rate、Ethernet（登録商標）等）とコントローラ（ＥＣＵ：Electronic Control Unit等）により構成される。第１の車両制御システム２は、第２の車両制御システム４、通信装置３、駆動装置５、認識装置６、出力装置７、入力装置８、及び通知装置９などと接続され、それぞれとの間で情報の送受信を行うように構成されている。
　通信装置３は、車両システム１の外部と無線通信（例えば、携帯電話の通信、無線ＬＡＮ、ＷＡＮ、Ｃ２Ｘ（Car to X：車両対車両または車両対インフラ通信）等のプロトコルを使用した通信、またはＧＰＳ（Global Positioning System）を用いた通信）を行い、外界（例えば、インフラ、他車、地図など）の情報または自車に関する情報（例えば、自車の状態を示す情報）を取得・送信などの無線通信を実施、または診断端子（ＯＢＤ）やEthernet（登録商標）端子、外部記録媒体（例えばＵＳＢメモリ、ＳＤカード、等）端子などを有し、第１の車両制御システム２と通信を実施するものである。
　第２の車両制御システム４は、例えば、第１の車両制御システム２と異なるプロトコル、或いは同一のプロトコルを用いたネットワークにより構成される車両制御システムである。
　駆動装置５は、第１の車両制御システム２の制御に従い、車両運動を制御する機械および電気装置（例えばエンジン、トランスミッション、ホイール、ブレーキ、操舵装置等）の駆動を行うものであり、例えばアクチュエータ等が該当する。
　認識装置６は、外界から入力される情報を取得し情報を生成するための情報を出力する、カメラ、レーダ、ＬＩＤＡＲ、超音波センサなどの外界センサ、および、車両システム１の状態（運動状態、位置情報、加速度、車輪速度等）を認識する力学系センサにより構成される。
　出力装置７は、ネットワークシステム（例えば、上述の車載ネットワーク）に有線または無線で接続され、ネットワークシステムから送出されるデータを受信し、メッセージ情報（例えば映像、音）など必要な情報を表示または出力する装置であり、例えば、液晶ディスプレイ、警告灯、スピーカなどが該当する。
　入力装置８は、ユーザが第１の車両制御システム２に対して、操作の意図や指示を入力する入力信号を生成するための装置であり、例えばステアリング、ペダル、ボタン、レバー、タッチパネル等が該当する。
　通知装置９は、車両システム１が外界に対して、車両の状態等を通知するための装置であり、例えば、ランプ、ＬＥＤ、スピーカ等が該当する。
　＜物理アーキテクチャの例＞
　図３は、車両制御システム２の物理アーキテクチャの例を示す図である。物理アーキテクチャ２０はＨ／Ｗ（Hardware）構成と呼ぶこともできる。
　物理アーキテクチャ２０は、例えば、ネットワークリンク３０１と、ＥＣＵ（Electronic Control Unit：電子制御ユニット）３０２と、によって構成される。
　ネットワークリンク３０１は、車載ネットワーク上のネットワーク装置を接続するためのネットワークリンクであり、例えばＣＡＮバスなどのネットワークリンクが該当する。
　ＥＣＵ３０２は、ネットワークリンク３０１および駆動装置５や認識装置６や３０１以外のネットワークリンク（専用線含む）に接続され、駆動装置５や認識装置６の制御および情報取得、ネットワークとのデータ送受信を行う。ＥＣＵ３０２は、複数のネットワークリンク３０１と接続され、それぞれのネットワークリンクとデータの送受信を行うゲートウェイ（以下ＧＷ）の役割をも担っている。
　ネットワークトポロジ構成例としては、図３に示す２つのバスに複数のＥＣＵが接続されているバス型の例以外にも、複数のＥＣＵが直接ＧＷに接続されるスター型や、ＥＣＵが一連のリンクにリング状に接続されているリンク型、それぞれの型が混在し複数のネットワークにより構成される混在型等を採用することもできる。ＥＣＵ３０２は、ネットワークから受信したデータを基に、駆動装置５への制御信号の出力、認識装置６からの情報の取得、ネットワークへの制御信号および情報の出力、内部状態の変更、などの制御処理を行う。
　本明細書では、ＥＣＵ３０２、ネットワークリンク３０１、およびＥＣＵ内のプロセッサを以下物理エレメントとも呼ぶこともある。
　＜ＥＣＵの内部構成例＞
　図４は、ＥＣＵ３０２の内部構成例を示す図である。ＥＣＵ３０２は、内部構成として、例えば、プロセッサ４０１と、Ｉ／Ｏ（Input/Output）デバイス４０２と、タイマ４０３と、ＲＯＭ（Read Only Memory）４０４と、ＲＡＭ（Random Access Memory）４０５と、内部バス４０６と、を備える。
　プロセッサ４０１は、キャッシュやレジスタなどの記憶素子を持ち、制御を実行するものであり、例えばＣＰＵなどで構成される。プロセッサ４０１は、後述する論理機能を実行する。
　Ｉ／Ｏデバイス４０２は、ネットワークリンク３０１またはネットワークや専用線で接続された駆動装置５または／および認識装置６に対してデータの送受信を行う。Ｉ／Ｏデバイス４０２は、例えば、通信Ｉ／Ｆ（Interface）デバイスで構成することができる。
　タイマ４０３は、図示しないクロックなどを使用し、時間および時刻の管理を行う。
　ＲＯＭ４０４は、プログラムおよび不揮発性のデータを保存する。ＲＡＭ４０５は、プログラムおよび揮発性のデータを保存する。内部バス４０６は、ＥＣＵ３０２内部での通信に用いられるバスである。
　＜物理アーキテクチャのパラメータ＞
　図５は、物理アーキテクチャ２０のパラメータ例を示す図である。図５Ａは、物理アーキテクチャ２０の物理エレメント（ＥＣＵやプロセッサ）に付与されるパラメータを示している。図５Ｂは、ネットワークに付与されるパラメータを示している。
（i）物理エレメントのパラメータ
　図５Ａに示されるように、物理エレメントのパラメータは、演算性能と、ＲＡＭ量と、ＲＯＭ量と、対応安全度と、コストと、多重度と、故障率と、診断率と、物理依存性と、を含む。これらのパラメータのうち、演算性能（ＭＨｚ：プロセッサの性能）、ＲＡＭ量（ＫＢ：容量）、ＲＯＭ量（ＫＢ：容量）、及びコスト（ｙｅｎ：ＥＣＵやプロセッサの価格）は、ＥＣＵまたはプロセッサの持つパラメータを有するアーキテクチャを定量評価する際に使用される。
　対応安全度は、安全性関連のパラメータであり、ハードウェア（ＥＣＵ）として対応可能な安全レベルを示す情報である。対応安全度はＩＳＯ２６２６２で規定されており、例えばＡＳＩＬ（Automotive Safety Integrity Level）やＱＭ（Quality Management）などが該当する。
　多重度は、ＥＣＵが有する系統数を示す情報である。例えば、ＥＣＵが２重系統を有し、１系統の故障に対応可能な場合には多重度は２（多重度の数）とされる。
　故障率は、物理エレメント（ＥＣＵやプロセッサ）が動作させ続けたときに故障が一回発生する時間（Failure in time）を示す情報であり、安全検証に使用される。
　診断率は、物理エレメントで有する機能（例えばマイコン診断など）の診断のカバレッジを示している。これは、例えば、診断率が９９％であれば、９９％の故障には対応できるが残り１％には対応できないことを示している。どの故障に対応できないかは設計時に分かっていることもある。
　物理依存性は、該当する物理エレメントがどのハードウェアに依存しているか（例えば、ＥＣＵが別のＥＣＵと同じ電源につながっている場合）を示す情報である。
　なお、図４に示されるように、ＥＣＵの内部にマイコン（プロセッサ）が配置されている場合、検証の際にはＥＣＵ、プロセッサのいずれかにパラメータが付与されており、そのどちらかのパラメータを使用する。このようにＥＣＵとマイコンの双方にパラメータが付与されている場合には、安全性を考慮し、より悪い結果を出力するパラメータ（例えばＡＳＩＬとして低い値）を検証に使用する。これにより、誤って高い検証結果を出すことがなくなり、全体としての安全性を確保することが可能となる。
　また、ここで、故障率及び診断率は、全ての故障モードに対して同じパラメータの例を記載しているが、各エレメントの故障モードごとに異なるパラメータとしても良い。このようにすることにより、故障モードに応じた故障率・診断率による検証および評価が可能になり、より詳細な定量評価、検証が可能となる。
（ii）ネットワークのパラメータ
　図５Ｂに示されるように、ネットワークは、通信速度（ｂｐｓ）、コスト（ｙｅｎ：ネットワークケーブルの価格）、及び多重度（通信線の冗長度）のパラメータを有する。
　＜論理アーキテクチャ＞
　図６は、車両制御システム（例えば、第１の車両制御システム２）の論理アーキテクチャ６０１の構成例を示す図である。
　車両制御システムの論理アーキテクチャ６０１は、例えば、統合認識部６０２と、自動運転制御部６０３と、ユーザ入力部６０４と、出力管理部６０５と、通知管理部６０６と、異常検出部６０７と、切替部６０８と、運動制御部６０９と、安全制御部６１０と、を備えている。
　統合認識部６０２は、複数の認識装置６、及び通信装置３から送信されてくる外界認識情報を統合した外界認識マップを作成する処理を実行する。
　自動運転制御部６０３は、統合認識部６０２により生成された外界認識マップ、及びユーザ入力部６０４から入力されたユーザ入力に基づいて、自動運転制御情報（軌道等）を生成し、異常検出部６０７、及び切替部６０８に出力する。また、自動運転制御部６０３は、出力管理部６０５に出力指示を行い、また、通知管理部６０６に通知指示を行う。出力管理部６０５は、自動運転制御部６０３および異常検出部６０７の出力に応じて出力装置７への出力指示を行う。通知管理部６０６は、自動運転制御部６０３および異常検出部６０７の出力に応じて通知装置９への通知指示を行う。
　ユーザ入力部６０４は、入力装置８からの入力に従い、ユーザの指示情報を生成する。
　異常検出部６０７は、自動運転制御部６０３からの自動運転制御情報等または図示しない各部からの所定情報に基づいて異常を検出し、異常検出結果を切替部６０８、安全制御部６１０、出力管理部６０５、及び通知管理部６０６に出力する。
　切替部６０８は、異常検出部６０７の異常検出結果等により、運動制御部６０９に対する出力を自動運転制御部６０３からの入力、ユーザ入力部６０４からの入力、または安全制御部６１０の入力に切替える。具体的には、異常検出部６０７によって異常が検出されると、自動運転制御部６０３からの通常制御系統（主制御系統ともいう：６０２→６０３→６０８→６０９）から異常時制御系統（安全制御系統ともいう：６０２→６１０→６０８→６０９）に切り替えられる。
　運動制御部６０９は、切替部６０８から提供される軌道情報または運動制御情報、認識装置６から取得する車両システム１の状態、及び駆動装置５からの応答に従って、複数の駆動装置５に対して制御を行う。
　安全制御部６１０は、異常検出の通知を受けた場合の制御を実施する。安全制御部６１０は、自動運転制御部６０３の縮退機能を有しており、緊急時（異常検出時）に自動運転制御部６０３の機能の一部を代替的に実行できるように構成されている。
　図６の例では、通常時に主要な制御を行う機能を主機能と呼び、異常の検出および異常発生後に主要な制御を行う機能を安全機能と呼ぶ。主機能には、統合認識部６０２、自動運転制御部６０３、ユーザ入力部６０４、出力管理部６０５、通知管理部６０６、及び運動制御部６０９が該当する。また、安全機能には、異常検出部６０７、切替部６０８、及び安全制御部６１０が該当する。
　＜論理アーキテクチャのパラメータ＞
　図７は、論理アーキテクチャ６０１のパラメータ例を示す図である。図７Ａは、主機能に付与されるパラメータを示している。図７Ｂは、安全機能に付与されるパラメータを示している。図７Ｃは、論理接続に対するパラメータを示している。
（i）主機能のパラメータ
　主機能のパラメータは、論理機能のタイプと、演算量と、消費ＲＡＭと、消費ＲＯＭとを含む。
　論理機能のタイプは、論理機能の種別を示す情報であり、主機能・安全機能の判定に使用される。ここでは「主機能」が入力される。
　演算量（ＭＨｚ）は、該当する機能を実行するために必要とされるＥＣＵ或いはプロセッサの性能を示す情報である。消費ＲＡＭ（ＫＢ）は、該当する機能を実行するために必要とされるＲＡＭの消費量を示す情報である。消費ＲＯＭ（ＫＢ）は、該当する機能を実行するために必要とされるＲＯＭの消費量を示す情報である。
　演算量、消費ＲＡＭ、及び消費ＲＯＭは、主にアーキテクチャの定量評価を行う際に使用される。
（ii）安全機能のパラメータ
　安全機能のパラメータは、論理機能のタイプと、安全機能のタイプと、安全制御モードと、演算量と、消費ＲＡＭと、消費ＲＯＭと、要求安全度と、検出対象と、検出故障モードと、検出率と、独立性要求と、を含む。
　論理機能のタイプは、論理機能の種別を示す情報であり、主機能・安全機能の判定に使用される。ここでは「安全機能」が入力される。演算量（ＭＨｚ）は、該当する機能を実行するために必要とされるＥＣＵ或いはプロセッサの性能を示す情報である。消費ＲＡＭ（ＫＢ）は、該当する機能を実行するために必要とされるＲＡＭの消費量を示す情報である。消費ＲＯＭ（ＫＢ）は、該当する機能を実行するために必要とされるＲＯＭの消費量を示す情報である。演算量、消費ＲＡＭ、及び消費ＲＯＭは、主にアーキテクチャの定量評価を実行する際に使用される。当該論理機能のタイプ、演算量、消費ＲＡＭ、及び消費ＲＯＭは、主機能と同様にアーキテクチャの定評評価を行う際に使用される。
　安全機能のタイプは、該当する安全機能の種別を示す情報であり、後述する安全機能連携の判断に使用される。例えば、安全機能のタイプは、検出・制御・切替のどの機能に該当するかを示す。
　安全制御モードは、該当する安全機能が実現すべき安全制御にどのような内容が要求されているかを示す情報である。例えば、機能停止、機能継続などの情報が付与される。また、安全制御モードには、要求される多重度の情報も含まれる。
　要求安全度は、該当する安全機能に要求される安全度を示す情報である。例えば、ＱＭやＡＳＩＬが付与され、該当する安全度での安全機能の実行が物理アーキテクチャ上で要求される。
　検出対象は、該当する安全機能がイベント（例えば、異常）を検出すべき対象となる論理機能を示す情報である。例えば、該当する機能が異常検出部６０７であるとき、検出対象は統合認識部６０２及び自動運転制御部６０３となる。
　検出故障モードは、複数の故障モード（例えば、故障時は停止、故障時は偽値出力、故障時は遅れて値を出力等）のうち該当する論理機能がどの故障モードに対応するかを示す情報である。
　検出率は、物理エレメントの「診断率」と同様、該当する安全機能においてどの程度の故障や誤りを検出することができるかを示す情報である。例えば、検出率９９％である場合、９９％の故障・誤りは検出できるが、残り１％の故障・誤りは検出できないことを意味している。
　独立性要求は、該当する安全機能について、故障発生時に同時に故障するべきではない論理機能名を示す情報である。独立性要求は、例えば、安全機能と主機能が同時に故障し、結果として安全制御が不可能となる、共通原因故障や従属故障といった設計を防ぐためのパラメータとなっている。
（iii）論理接続のパラメータ
　論理接続に対するパラメータは、該当する通信路の通信量を含む。当該通信量は、アーキテクチャを定量評価する際に使用される。
（iv）以上説明したパラメータについては、アーキテクチャ設計時に必須の組み合わせがある。従って、必須のパラメータが付与されていない場合には、アーキテクチャ検証時にＮＧとして判断する必要がある。例えば、安全機能のタイプが「検出」であるにも拘らず、検出対象、検出故障モード、及び検出率等のパラメータが付与されていない場合には安全性検証時にＮＧが出力される。
　＜機能配置例＞
　図８は、論理アーキテクチャが物理アーキテクチャに配置された場合の構成例を示す図である。
　機能配置部１０１は、与えられた論理アーキテクチャ６０１（図６参照）を、与えられた物理アーキテクチャ２０（図３参照）上に配置する。これにより、どの論理機能の処理がどの物理エレメント（ＥＣＵ、マイコン）上で実行され、ネットワークでの通信にどのような内容が実施されるかが決定される。
　図８の配置例では、互いに関連性が強い論理機能が同一のＥＣＵに配置される。例えば、主機能である、統合認識部６０２と自動運転制御部６０３、及びユーザ入力部６０４と出力管理部６０５がそれぞれ同一のＥＣＵに配置される。安全機能である異常検出部６０７と安全制御部６１０が同一のＥＣＵに配置される。また、安全機能である切替部６０８と主機能である運動制御部６０９が同一のＥＣＵに配置される。
　なお、論理機能間で、ネットワークで複数の経路がある場合には、例えばその中で最小のコスト（通信帯域、ホップ数）となる経路を選択するなどして効率の良い通信を実施することが好ましい。
　＜安全分析情報＞
　図９は、安全分析情報として用いることができるＦＴＡ（Fault Tree Analysis）の例を示す図である。ＦＴＡ９００は、ツリー状の構造を表しており、トップイベント（トップ事象）９０１と、それぞれの葉となるイベント９０３と、分岐のゲート９０２と、を含んでいる。
　トップイベント（ツリーの最上部の事象）は、ハザードイベント（危険な事象）とされ、ＡＮＤやＯＲのゲートで下位の事象と連結され、トップイベントの発生原因となる下位イベントに分解される。ＯＲのゲートは、どちらかの事象が発生した場合に上位の事象が発生することを意味し、ＡＮＤのゲートは両方の事象が発生した場合にのみ上位の事象が発生することを意味する。このようにして最上位のハザードを発生させるイベントの関係性を明確化することができる。
　＜イベント及びゲートのパラメータ＞
　図１０は、各イベントおよび各ゲートに付与するパラメータの例を示す図である。図１０Ａは、各イベントに付与するパラメータを示している。図１０Ｂは、各ゲートに付与するパラメータを示している。
（i）イベントのパラメータ
　イベントのパラメータは、該当するイベントの上位に位置するイベント（上位イベント）又はゲート（上位ゲート）と、イベント種別（中間イベントか基本イベントか）と、故障機能と、故障モードと、を構成項目として有している。故障機能と故障モードの組み合わせでイベントの内容が表わされている。故障機能と故障モードについては、基本事象だけでなく、中間事象にも記載する。そのようにすることにより、例えばコンポーネントの故障だけでなくシステムレベルでの故障についても記載可能である。
　なお、故障機能に関しては、論理機能の内容を示すテーブル（図示せず）が別途用意されており、当該テーブルを参照することにより各論理機能の内容を把握することができるようになっている。
（ii）ゲートのパラメータ
　ゲートのパラメータは、各ゲートの上位に位置するイベントまたはゲートと、ゲートの種別（ＯＲまたはＡＮＤ）と、を構成項目として有している。
（iii）以上のパラメータにより、いずれかのイベント（論理機能の故障）が発生した場合に、どのような条件でハザードが発生するかを表現することが可能になる。
　＜安全性検証処理＞
　図１１は、第１の実施形態による安全性検証処理の概要を説明するためのフローチャートである。以下では、プログラムとしての安全性検証部１０２を動作主体として処理概要について説明するが、プログラムは車両制御システム検証装置１００のプロセッサによって読み込まれ、実行されるものであるので、安全性検証部１０２を「プロセッサ」と読み替えることも可能である。
（i）ステップ１１０１
　安全性検証部１０２は、まず、機能配置後のアーキテクチャについて安全要件検証処理を実行する。安全要件検証処理の詳細については後述する（図１２参照）。
（ii）ステップ１１０２
　安全性検証部１０２は、安全要件の検証結果がＯＫの場合には（Ｓ１１０２でｙｅｓ）、処理をステップ１１０３に移行させ、安全要件の検証結果がＮＧの場合には（Ｓ１１０２でｎｏ）、処理をステップ１１０４に移行させる。
（iii）ステップ１１０３
　安全性検証部１０２は、安全性検証結果としてＯＫを出力して処理を終了する。
（iv）ステップ１１０４
　安全性検証部１０２は、ＮＧ結果とその理由、及び何れの安全要件の検証がＮＧであったかを出力する。このようにして安全要件の検証が実施される。
　＜安全要件検証処理＞
　図１２は、安全要件検証処理（ステップ１１０２）の詳細を説明するためのフローチャートである。
（i）ステップ１２０１
　安全要件検証処理において、安全性検証部１０２は、安全分析情報９００の全てのイベントについてステップ１２０２～ステップ１２０５の処理を繰り返す。
（ii）ステップ１２０２
　安全性検証部１０２は、それぞれのイベントについて、対応する安全機能がアーキテクチャ上に存在しているかを確認する。具体的には、該当する（処理対象の）イベント（例えば、ＥＴ３）の故障機能（例えば、図１０の論理機能１）のパラメータが、対応する安全機能における検出故障モードと検出対象に存在するかチェックされる。対応する安全機能がある場合（ステップ１２０２でｙｅｓの場合）、処理はステップ１２０３に移行する。対応する安全機能がない場合（ステップ１２０２でｎｏの場合）、処理はステップ１２０５に移行する。
（iii）ステップ１２０３
　安全性検証部１０２は、物理アーキテクチャ２０における、該当する安全機能の配置先において、安全度及び多重度の要件を満たしているか判定する。
　安全度の場合には、該当する安全機能のパラメータである要求安全度の値が、配置先の物理エレメントの対応安全度より小さいか、または等しい場合にはＯＫと判定される。具体的には、安全機能の要求安全度がＡＳＩＬ－Ｃの場合、配置先の物理エレメントの対応安全度がＡＳＩＬ－Ｃかそれ以上（ＡＳＩＬ－Ｄ等）の場合にＯＫと判定される。
　多重度の場合には、該当する安全機能のパラメータである安全制御モードに含まれる要求多重度の値が、配置先の物理エレメントの多重度より小さいまたは等しい場合にはＯＫと判定される。具体的には、安全機能の要求多重度が２の場合、配置先の物理エレメントの多重度が２以上の場合にＯＫと判定される。
　配置先の安全度及び多重度がＯＫの場合（ステップ１２０３でｙｅｓの場合）、処理はステップ１２０４に移行する。配置先の安全度及び多重度がＮＧの場合（ステップ１２０３でｎｏの場合）、処理はステップ１２０５に移行する。
（iv）ステップ１２０４
　安全性検証部１０２は、該当するイベントの内容をＯＫとする。
（v）ステップ１２０５
　安全性検証部１０２は、該当するイベントの内容をＮＧとする。
（vi）ステップ１２０６
　安全性検証部１０２は、次のイベントについて処理を行う。全てのイベントについて処理が完了した後、処理はステップ１２０７に移行する。
（vii）ステップ１２０７
　安全性検証部１０２は、ステップ１２０１～ステップ１２０６の処理結果をＦＴＡのツリーに適用して安全要件検証の判定を行う。具体的には、安全性検証部１０２は、ＦＴＡの各イベントについて、上記各イベントのＯＫ及びＮＧの結果をＦＴＡに入力し、ＦＴＡのツリーに従って判定を行う。つまり、各イベントから上部にＯＫ、ＮＧを辿り、各ゲートでの判定をＡＮＤ、ＯＲとして判定し、最上位のイベントが発生するかを判定する。ここでは、安全性検証部１０２は、ＮＧをＴ（Ｔｒｕｅ）、ＯＫをＦ（Ｆａｌｓｅ）とし、ＡＮＤ条件及びＯＲ条件で判定を行い、トップイベント（トップ事象）がＦａｌｓｅの場合にはＯＫを返し、Ｔｒｕｅの場合にはＮＧを返す。このようにして全体での安全要件の検証が行われる。
　なお、ＮＧの場合には、記録されたＮＧイベントの全てを返すようにする。これにより、車両制御システム検証装置１００は、ユーザに対して不備のあった安全要件を提示することが可能になる。
（viii）変形例
　ステップ１２０３においては、配置先の検証処理では安全度の判定だけを実施しても良い。多重度は別途安全機能連携の検証でも実施するため、ステップ１２０３では省略可能である。これにより、演算量の削減が可能となる。
　また、ステップ１２０７においては、ＦＴＡツリーでの判定を行わず、いずれかのイベントでＮＧがあった場合に、その結果を基に安全要件検証をＮＧと判定し、安全要件検証処理を終了しても良い。全ての安全要件には安全機能が対応すべきとして判定することにより、ＦＴＡツリーの演算を行わず、処理時間を短縮することが可能となる。
　＜アーキテクチャ定量評価＞
　アーキテクチャ定量評価部１０３は、機能配置済みのアーキテクチャで安全性検証結果がＯＫと判定されたアーキテクチャの定量評価を行う。定量評価は、例えば、物理エレメント上の論理機能の使用率の算出、通信の占有率の算出、及び物理エレメントのコストの算出することにより実現することができる。物理エレメント上の論理機能の使用率は、物理アーキテクチャ２０の物理エレメントに配置された複数の論理機能について、演算量、消費ＲＡＭ、及び消費ＲＯＭのそれぞれについて合計値を算出し、物理エレメント上での使用率を計算することにより算出することができる。また、通信の占有率は、ネットワーク上の各論理機能による通信の使用量を合計し、占有率を計算することにより算出することができる。さらに、物理エレメントのコストは、物理アーキテクチャ全体で使用している物理エレメント、つまり論理機能が１つ以上配置されている物理エレメントについてのコストを合計することにより算出することができる。
　これらの計算により、安全性が検証されたアーキテクチャの定量評価が可能となる。なお、安全性が検証済みのアーキテクチャのみを定量評価するようにしても良い。これにより、安全性を満たさない不要なアーキテクチャ評価時間を削減することが可能となる。
（２）第２の実施形態
　第２の実施形態は、安全性の定量的評価に基づく検証および評価の別形態について開示する。具体的には、第１の実施形態における安全要件検証（ステップ１１０１）、または上述のアーキテクチャ定量評価で実行される、別形態の処理（安全性定量評価処理：トップイベント発生確率算出処理と呼ぶことも可能）について説明する。
　＜安全性定量評価処理（トップイベント発生確率算出処理）の概要＞　図１３は、第２の実施形態による安全性定量評価処理の概要を示す図である。当該処理は、トップイベントが発生する確率を算出処理に相当する。
　ＦＴＡを構成する複数のイベントのうち１つを選択し、当該イベントに対応する論理機能の検出対象（図７参照）とイベントに対応する論理機能の故障機能及び故障モード（図１０参照）とから、主機能及び安全機能が特定される。
　特定された主機能に対応する物理エレメントの故障率（図５参照）、及び主機能の故障を検出する安全機能の検出率（図７参照）が取得される。
　次に、取得された故障率及び検出率から残存故障率（検出できない故障の割合）が算出される。
　そして、ツリーの条件に合わせて各イベントの残存故障率を積算し、トップイベントの発生確率が算出される。
　＜安全性定量評価処理（トップイベント発生確率算出処理）の詳細＞　図１４は、第２の実施形態による安全性定量評価処理の詳細を説明するためのフローチャートである。アーキテクチャ定量評価部１０３は、以下の手順に従って、該当するハザード（トップイベント）の発生確率（残存故障率）を計算する。ここでは、プログラムとしてのアーキテクチャ定量評価部１０３を動作主体として処理内容を説明するが、プログラムは車両制御システム検証装置１００のプロセッサによって読み込まれ、実行されるものであるので、アーキテクチャ定量評価部１０３を「プロセッサ」と読み替えることも可能である。
（i）ステップ１４０１及び１４０６
　アーキテクチャ定量評価部１０３は、安全分析情報（ＦＴＡ）の全てのイベントについてステップ１４０２～ステップ１４０５の処理を繰り返す。
（ii）ステップ１４０２
　アーキテクチャ定量評価部１０３は、処理対象のイベントについて、該当する主機能と安全機能を探索する。主機能については、イベントに対応する論理機能（安全機能）の検出対象に検出（監視と言い換えることができる）の対象となる論理機能（主機能）が記載されているので、この情報が抽出される（図１３の例では主機能Ａ）。
　安全機能については、処理対象のイベントの故障機能と故障モード（図１０参照）から、対応する安全機能（ここでは安全機能Ａ）が特定される。
（iii）ステップ１４０３
　アーキテクチャ定量評価部１０３は、該当する故障モードに対応する故障率であって、主機能Ａが配置されているＥＣＵまたはマイコン（ここではＥＣＵ２）のパラメータに記載される故障率（図５参照）を取得する。
（iv）ステップ１４０４
　アーキテクチャ定量評価部１０３は、探索した安全機能（安全機能Ａ）の検出率を当該安全機能のパラメータ（図７参照）から取得する。
（v）ステップ１４０５
　アーキテクチャ定量評価部１０３は、取得した故障率及び検出率を（式１）に適用して処理対象のイベントの残存故障率を計算する。
　残存故障率＝故障率×（１－検出率）・・・（式１）
　ここでは、検出された故障は確実に処理されるものとして計算している。なお、該当する安全機能が無かった場合には、検出率を０として計算される。
（vi）ステップ１４０７
　アーキテクチャ定量評価部１０３は、全てのイベントの残存故障率を計算した後、トップイベントの発生確率をＦＴＡツリーの構造に従って計算する。ここでは、各イベントの残存故障率を算出した後に、ＡＮＤまたはＯＲゲートの演算に従ってトップイベントの発生確率が計算される。また、ここでは、全ての事象を独立と考え、ＯＲゲートではそれぞれのイベントの残存故障率を加算し、ＡＮＤゲートではそれぞれのイベントの残存故障率の掛け算により上位のイベントの発生率が計算される。このようにして安全性の定量評価が実施される。
　なお、安全性定量評価の実施を安全要件検証処理（ステップ１１０１）で実行する場合には、例えば、ハザードの残存故障率を、ハザードごとの要求値（例えばＡＳＩＬ－Ｄで１０ＦＩＴ等）と比較し、その値以下であることから検証ＯＫと判断する。
（３）第３の実施形態
　第３の実施形態は、安全性検証処理において、安全機能連携を検証する処理（安全機能連携検証処理）を実行することについて開示する。第１の実施形態との差異は、図１１の安全性検証処理に安全機能連携検証処理がさらに実行される点である。以下、第３の実施形態による安全性検証処理について説明する。
　＜安全性検証処理の概要＞
　図１５は、第３の実施形態による安全性検証処理の概要を説明するためのフローチャートである。図１５に示されるように、第１の実施形態による安全性検証処理（図１１：ステップ１１０１～ステップ１１０４）にステップ１５０１及びステップ１５０２が追加されている。以下、追加された処理についてのみ説明する。
（i）ステップ１５０１
　安全性検証部１０２は、論理機能を配置した後の物理アーキテクチャにおける安全機能の連携について検証する。当該処理の詳細については後述する（図１６参照）。
（ii）ステップ１５０２
　安全性検証部１０２は、ステップ１５０１の処理の結果、安全機能連携の検証結果がＯＫであったか否か判定する。所望の安全機能連携が行われている場合（ステップ１５０２でｙｅｓの場合）、処理はステップ１１０３に移行する。所望の安全機能連携が行われていない場合（ステップ１５０２でｎｏの場合）、処理はステップ１１０４に移行する。
　＜安全機能連携検証処理の詳細＞
　図１６は、安全機能連携検証処理（ステップ１５０１）の詳細を説明するためのフローチャートである。以下では、プログラムとしての安全性検証部１０２を動作主体として安全機能連携検証処理について説明するが、プログラムは車両制御システム検証装置１００のプロセッサによって読み込まれ、実行されるものであるので、安全性検証部１０２を「プロセッサ」と読み替えることも可能である。
（i）ステップ１６０１
　安全機能連携検証処理は、論理アーキテクチャの全ての安全機能について実行されるため、安全性検証部１０２は、最初に該当する安全機能のパラメータから安全制御モードを取得する。安全制御モードには機能継続や安全停止等が含まれ、該当する安全機能に対応してその情報が取得される。
（ii）ステップ１６０２
　安全性検証部１０２は、安全制御モードに合わせ、安全機能の連携が正しく行われているかについて、論理機能をチェックする。ここで、論理機能のチェックとは、取得した安全制御モードに対応した論理機能の連携が行われているか、安全制御モデル（図７参照）と安全機能の連携を比較することを意味する。図１７は、安全制御モデルの例を示す図である。図１７Ａは、安全制御モードの「安全停止」に対応した安全制御モデルの例を示している。図１７Ｂは、安全制御モードの「機能継続」に対応した安全制御モデルの例を示している。図１７中「Ｓ」はSensorを示し、「Ａ」はActuatorを示す。
　図１７Ａの「安全停止」に対応した安全制御モデルでは、パラメータの安全機能タイプ（図７参照）で「検出」機能を持つ安全機能（安全機能Ａ）が、パラメータの検出対象（図７参照）で指定されている主機能Ａ、Ｂ、Ｃと連結されている。また、主機能Ｃの出力が安全機能タイプ（図７参照）で「切替」機能を持つ安全機能（安全機能Ｂ）へと入力されている。安全制御モードで「安全停止」が指定されている場合にはこのような連携が必要となるため、安全性検証部１０２は、このような連携が論理アーキテクチャ上で構築されているか否かチェックする。
　図１７Ｂの「機能継続」に対応した安全制御モデルでは、パラメータの安全機能タイプ（図７参照）で「検出」機能を持つ安全機能（安全機能Ａ）が、パラメータの検出対象（図７参照）で指定されている主機能Ａ、Ｂ、Ｃと連結されている点は同様である。一方、「機能継続」を行う場合には、「機能継続」のための制御を行う安全機能が必要となり、検出結果の出力が安全機能タイプ（図７参照）で「制御」機能を持つ安全機能（安全機能Ｃ）へと入力されている。当該安全機能Ｃは、「制御」を行うための入力（Ｓ）をも有している。そして、当該安全機能（安全機能Ｃ）の出力結果が「切替」を行う安全機能（安全機能Ｂ）へと入力される。安全制御モードで「機能継続」が指定されている場合にはこのような連携が必要となるため、安全性検証部１０２は、このような連携が論理アーキテクチャ上で構築されているか否かチェックする。
（iii）ステップ１６０３
　安全性検証部１０２は、ステップ１６０２における安全機能連携のチェック結果がＯＫであるか判定する。チェック結果がＮＧであった場合（ステップ１６０３でｎｏの場合）、処理はステップ１６０４に移行する。チェック結果がＯＫであった場合（ステップ１６０３でｙｅｓの場合）、処理はステップ１６０５に移行する。
（iv）ステップ１６０４
　ステップ１６０３で論理機能チェックの結果がＮＧであった場合、安全性検証部１０２は、該当する安全要件のチェック結果がＮＧであったこととその理由を出力する。この場合、論理機能チェックＮＧとなる安全要件、またそこで不足していた論理機能の連携の情報が出力される。
　ステップ１６０６で安全要件のチェック結果がＮＧであった場合、安全性検証部１０２は、ＮＧ結果とＮＧ理由を出力する。この場合、ＮＧ理由には安全度及び／又は多重度が不足していた安全要件と経路の情報が出力される。
（v）ステップ１６０５
　安全性検証部１０２は、ステップ１６０３で確認した安全機能の連携について、配置先と経路の安全要件をチェックする。
　図１８は、安全機能の連携に関する配置先と経路の安全要件のチェック例を示す図である。図１８Ａは、安全機能Ａと安全機能Ｂが連携しており、その機能の安全度の要求がＡＳＩＬ－Ｄの例を示している。図１８Ｂは、さらに安全機能の安全制御モードとして機能継続が指定されている場合の評価例を示している。
　図１８Ａの場合、安全性検証部１０２は、配置先のＥＣＵ１とＥＣＵ３、その中間のＮＷ（ネットワーク）１、ＥＣＵ２、及びＮＷ２についても要求の安全度（ＡＳＩＬ－Ｄ）を満たしているか否か確認する。また、多重度についても同様に確認する。このようにして機能連携時の安全要件のチェックが行われる。
　図１８Ｂの場合、図１８Ｂに示す通りに各機能が配置されている。安全機能の連携については図１８Ａの場合と同様に安全度の判定が行われる。また、図１８Ｂの場合、「機能継続」のための機能が追加されている。「機能継続」の場合には主機能と安全機能で独立し、かつ冗長化した経路が必要となる。主機能による経路が故障等によって使えない場合には別の経路で故障した主機能と同様の機能が実現される必要があるからである。そこで、安全性検証部１０２は、経路探索アルゴリズムにより独立した別の経路があるか検索を行う。独立した経路があり（図１８ＢのＥＣＵ２→ＮＷ２→ＥＣＵ３→ＮＷ６→ＥＣＵ６と、ＥＣＵ４→ＮＷ４→ＥＣＵ５→ＮＷ５→ＥＣＵ６の２つの経路）、さらにそれら経路が所定の安全度を満たしている場合には、安全要件のチェックをＯＫと判定する。なお、上記では「別の経路」と記したが、完全に別の経路が存在する場合だけでなく、ネットワークやＥＣＵが冗長化（内部で多重化）されている構成でも良い。その場合には経路での物理エレメントの多重度が要求されている多重度を超えているか否かで判定することができる。
（vi）ステップ１６０６
　安全性検証部１０２は、ステップ１６０５で得られた安全機能連携の安全要件チェック結果がＯＫか否か判断する。安全要件チェック結果がＮＧであった場合（ステップ１６０６でｎｏの場合）、処理はステップ１６０４に移行する。安全要件チェック結果がＯＫであった場合（ステップ１６０６でｙｅｓの場合）、処理はステップ１６０７に移行する。
（vii）ステップ１６０７
　安全性検証部１０２は、ＯＫ結果（安全機能連携の安全要件チェックの結果がＯＫであること）を出力する。
（４）第４の実施形態
　第４の実施形態は、車両制御システムの安全性検証を車両制御システム内で実行するための構成について開示する。
　＜車両制御システム構成＞
　図１９は、第４の実施形態による車両制御システムの構成（物理アーキテクチャ）例を示す図である。図１９では、図１に示す車両制御システム検証装置１００がＥＣＵ３０２に配置され、与えられるＦＴＡに基づいて安全性検証処理が車両制御システム内で実行される。第１乃至第３の実施形態では、主に設計時に安全性検証処理が実行されるが、第４の実施形態では、車両制御システム検証装置１００が車両制御システム内に実装されているため、例えば、制御プログラムを書き換えたようなときに安全性検証処理を実行することが可能となる。
　第４の実施形態において、車両制御システム検証装置１００は、ネットワークリンク３０１を通じてアーキテクチャ情報を収集する。
　＜アーキテクチャ構成情報＞
　図２０は、第４の実施形態において車両制御システム検証装置１００が受信するアーキテクチャ構成情報の例を示す図である。図２０Ａは、物理アーキテクチャ構成情報を示している。図２０Ｂは、論理アーキテクチャ構成情報を示している。
　物理アーキテクチャ構成情報（図２０Ａ）は、各物理エレメント名（ＥＣＵ、マイコン）と、該当する物理エレメントと接続しているネットワーク名と、物理エレメントの各種パラメータ（図５参照）と、を構成項目として含んでいる。当該物理アーキテクチャ情報は、車両制御システム検証装置１００が、複数のＥＣＵから、それぞれが所有している情報を収集することによって構築される。
　論理アーキテクチャ構成情報（図２０Ｂ）は、各論理機能名（ＩＤ）と、配置されている物理エレメント名（配置場所）と、論理アーキテクチャのパラメータ（図７参照）と、を構成項目として含んでいる。当該論理アーキテクチャ情報も、車両制御システム検証装置１００が、複数のＥＣＵから、それぞれが所有している情報を収集することによって構築される。
　車両制御システム検証装置１００は、物理アーキテクチャ構成情報及び論理アーキテクチャ情報以外に、ＥＣＵ３０２やネットワークリンク３０１に予め保持された安全分析情報を収集する。そして、車両制御システム検証装置１００は、車両制御システム検証及び安全性検証の処理を実行し、ネットワーク等に検証結果を出力する。これにより、車両制御システムの状態について常に安全性の検証を実施することが可能となる。
　ネットワークで取得される、物理アーキテクチャ構成情報、論理アーキテクチャ構成情報、及び安全分析情報については、全ての情報を取得する必要は無く、差分だけを受信し、車両制御システム検証装置１００が差分の更新のみを行い判定をしても良い。そのようにすることにより、通信量を削減することが可能となる。
（５）まとめ
（i）本開示の車両制御システム検証装置は、与えられる安全分析結果の情報に基づいて、車両制御システムの論理アーキテクチャが安全分析結果に対応する論理機能（安全機能）を有するか否かを検証する。このようにすることにより、車両制御システムのアーキテクチャの安全性を網羅的に（一部ではなく）検証することができるようになる。上記論理アーキテクチャは安全分析結果（ＦＴＡ）の情報に基づいて構築されたものであっても良い。これにより、安全分析結果の要件を充足するように設定したアーキテクチャが本当に安全分析結果に対応できるか検証することができるようになる。さらに、車両制御システム検証装置は、論理アーキテクチャが配置される物理アーキテクチャが論理アーキテクチャで要求される安全度及び多重度を満足するか否かを検証する。これにより、論理アーキテクチャ上での安全性を検証できるだけでなく、物理アーキテクチャ上での安全性を検証することができるようになる。また、例えば、安全分析結果がＦＴＡであるとき、ＦＴＡにおける複数のイベントに対応する論理アーキテクチャの安全性検証の結果と物理アーキテクチャの安全性検証の結果とをＦＴＡに当てはめたときにトップイベントが発生するか否かを判定することにより、設計されたアーキテクチャが適切であるか否か効果的に評価することができるようになる。
　また、本開示の車両制御システム検証装置は、物理アーキテクチャ（例えば、複数の物理エレメントとネットワークを含む）を定量評価する。具体的には、論理アーキテクチャを物理エレメントに配置したときの、複数の物理エレメントの使用率と、ネットワークの占有率を算出することにより、物理アーキテクチャの定量評価を行うことができる。
（ii）定量評価の別の形態として、本開示の車両制御システム検証装置は、ＦＴＡの複数のイベントのそれぞれについて、論理アーキテクチャにおける、各イベントに対応する論理アーキテクチャの論理機能の残存故障率を、当該論理機能のパラメータである故障率と検出率とから算出し、当該各イベントに対応する論理機能の残存故障率をＦＴＡに適用してトップイベントの残存故障率を算出する。このようにすることにより、安全機能が適切であった場合であってもトップイベント（例えば、危険性のある故障）が発生してしまう確率を提供することが可能となる。そして、この結果に基づいて、さらなるアーキテクチャの改良（故障率を下げたり、検出率を上げたりする）が必要であるか考察することが可能となる。
（iii）本開示の車両制御システム検証装置は、異常発生時に論理アーキテクチャが実現すべき制御内容を示す安全制御モードに対応して各論理機能が連携動作するか否かチェックする。例えば、安全制御モードが安全停止である場合には、異常を検出する機能を有する安全機能と、異常を検出する対象の主機能と、切替機能を有する安全機能とが連携して動作するか否かチェックされる。また、安全制御モードが機能継続である場合には、異常を検出する機能を有する安全機能と、異常を検出する対象の主機能と、代替制御を行う機能を有する安全機能と、切替機能を有する安全機能とが連携して動作するか否かチェックされる。このようにすることにより、アーキテクチャにおける安全機能の連携について検証することができるようになる。また、各安全制御モードの種類に応じた機能連携について検証することができるようになる。
（iv）本開示の車両制御システム検証装置は、車両制御システムの物理アーキテクチャ内に配置することも可能である。この場合、車両制御システム検証装置は、外部から入力される、車両制御システムの論理アーキテクチャ及び物理アーキテクチャの情報と安全分析結果の情報を取得し、これらに基づいて、アーキテクチャの安全性について検証する。例えば、論理アーキテクチャについては、それが安全分析結果（ＦＴＡ）に対応する論理機能（安全機能）を有するか否か検証される。物理アーキテクチャについても、要求される安全度及び多重度が充足されるか検証される。このように車両制御システム内に当該車両　
制御システム検証装置を実装することにより、例えば、制御プログラムを書き換えたような場合にも車両制御システムの安全性を検証することができるようになる。
（v）本開示の実施形態は、その機能を実現するソフトウェアのプログラムコードによっても実現できる。この場合、プログラムコードを記録した記憶媒体をシステム或は装置に提供し、そのシステム或は装置のコンピュータ（又はＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読み出す。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコード自体、及びそれを記憶した記憶媒体は本発明を構成することになる。このようなプログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク、ＣＤ－ＲＯＭ、ＤＶＤ－ＲＯＭ、ハードディスク、光ディスク、光磁気ディスク、ＣＤ－Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭなどが用いられる。
　また、プログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳ（オペレーティングシステム）などが実際の処理の一部又は全部を行い、その処理によって前述した実施の形態の機能が実現されるようにしてもよい。さらに、記憶媒体から読み出されたプログラムコードが、コンピュータ上のメモリに書きこまれた後、そのプログラムコードの指示に基づき、コンピュータのＣＰＵなどが実際の処理の一部又は全部を行い、その処理によって前述した実施の形態の機能が実現されるようにしてもよい。
　さらに、実施の形態の機能を実現するソフトウェアのプログラムコードを、ネットワークを介して配信することにより、それをシステム又は装置のハードディスクやメモリ等の記憶手段又はＣＤ－ＲＷ、ＣＤ－Ｒ等の記憶媒体に格納し、使用時にそのシステム又は装置のコンピュータ（又はＣＰＵやＭＰＵ）が当該記憶手段や当該記憶媒体に格納されたプログラムコードを読み出して実行するようにしても良い。
　最後に、ここで述べたプロセス及び技術は本質的に如何なる特定の装置に関連することはなく、コンポーネントの如何なる相応しい組み合わせによってでも実装できることを理解する必要がある。更に、汎用目的の多様なタイプのデバイスがここで記述した教授に従って使用可能である。ここで述べた方法のステップを実行するのに、専用の装置を構築するのが有益であることが判るかもしれない。また、実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。本開示は、具体例に関連して記述したが、これらは、すべての観点に於いて限定の為ではなく説明の為である。本分野にスキルのある者には、本開示を実施するのに相応しいハードウェア、ソフトウェア、及びファームウエアの多数の組み合わせがあることが解るであろう。例えば、記述したソフトウェアは、アセンブラ、Ｃ／Ｃ＋＋、ｐｅｒｌ、Ｓｈｅｌｌ、ＰＨＰ、Ｊａｖａ（登録商標）等の広範囲のプログラム又はスクリプト言語で実装できる。
　さらに、上述の実施形態において、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。全ての構成が相互に接続されていても良い。
　加えて、本技術分野の通常の知識を有する者には、本開示のその他の実装がここに開示された本開示の明細書及び実施形態の考察から明らかになる。記述された実施形態の多様な態様及び／又はコンポーネントは、単独又は如何なる組み合わせでも使用することが出来る。明細書と具体例は典型的なものに過ぎず、本開示の範囲と着想は後続する特許請求範囲で示される。
１　車両システム２　車両制御システム３　通信装置４　車両制御システム５　駆動装置６　認識装置７　出力装置８　入力装置９　通知装置２０　物理アーキテクチャ１００　車両制御システム検証装置１０１　機能配置部１０２　安全性検証部、１０３　アーキテクチャ定量評価部３００　物理アーキテクチャ３０１　ネットワークリンク３０２　ＥＣＵ４０１　プロセッサ４０２　Ｉ／Ｏデバイス４０３　タイマ４０４　ＲＯＭ４０５　ＲＡＭ４０６　内部バス６０１　論理アーキテクチャ６０２　統合認識部６０３　自動運転制御部６０４　ユーザ入力部６０５　出力管理部６０６　通知管理部６０７　異常検出部６０８　切替部６０９　運動制御部６１０　安全制御部９００　安全分析情報９０１　トップイベント９０２　ゲート９０３　イベント

Claims (12)

  1. 　車両制御システムの論理アーキテクチャの安全性を検証するためのプログラムを格納する記憶デバイスと、
    　前記記憶デバイスから前記プログラムを読み込み、前記論理アーキテクチャの安全性を検証するプロセッサと、を備え、
    　前記プロセッサは、与えられる安全分析結果の情報に基づいて、前記論理アーキテクチャが前記安全分析結果に対応する論理機能を有するか否かを検証する第１の検証処理を実行する、車両制御システム検証装置。
  2. 　請求項１において、
    　前記論理アーキテクチャは、前記安全分析結果の情報に基づいて構築されたものである、車両制御システム検証装置。
  3. 　請求項１において、
    　前記論理アーキテクチャは、前記車両制御システムの物理アーキテクチャに配置され、
    　前記プロセッサは、さらに、前記物理アーキテクチャが前記論理アーキテクチャで要求される安全度及び多重度を満足するか否かを検証する第２の検証処理を実行する、車両制御システム検証装置。
  4. 　請求項３において、
    　前記安全分析結果の情報は、複数のイベントの発生と最終結果であるトップイベントの発生との関係をツリー構造で表すＦＴＡであり、
    　前記プロセッサは、さらに、
    　　前記ＦＴＡにおける前記複数のイベントに対応する前記第１の検証処理の結果と前記第２の検証処理の結果とを前記ＦＴＡに当てはめたときに前記トップイベントが発生するか否かを判定する処理と、
    　　前記判定する処理の結果を出力する処理と、を実行する、車両制御システム検証装置。
  5. 　請求項４において、
    　前記判定する処理の結果が前記トップイベントの発生を示す場合、前記プロセッサは、さらに、前記物理アーキテクチャの定量評価を行う処理を実行する、車両制御システム検証装置。
  6. 　請求項５において、
    　前記物理アーキテクチャは、複数の物理エレメントとネットワークとを含み、
    　前記プロセッサは、前記定量評価を行う処理において、前記論理アーキテクチャを前記物理エレメントに配置したときの、前記複数の物理エレメントの使用率と、前記ネットワークの占有率を算出することにより、前記物理アーキテクチャの定量評価を行う、車両制御システム検証装置。
  7. 　請求項５において、
    　前記プロセッサは、前記定量評価を行う処理において、
    　　前記複数のイベントのそれぞれについて、前記論理アーキテクチャにおける、各イベントに対応する前記論理アーキテクチャの論理機能の残存故障率を、当該論理機能のパラメータである故障率と検出率とから算出する処理と、
    　　前記算出された各イベントに対応する論理機能の残存故障率を前記ＦＴＡに適用して前記トップイベントの残存故障率を算出する処理と、を実行する、車両制御システム検証装置。
  8. 　請求項１において、
    　前記プロセッサは、さらに、前記車両制御システムの異常発生時に前記論理アーキテクチャが実現すべき制御内容を示す安全制御モードの情報を取得し、前記安全制御モードに対応する、前記論理アーキテクチャの各論理機能が連携して動作するか否かチェックする処理を実行する、車両制御システム検証装置。
  9. 　請求項８において、
    　前記論理アーキテクチャの論理機能は、前記車両制御システムにおいて所定の機能を実現するための主機能と、前記車両制御システムの異常に対応するための安全機能と、によって構成され、
    　前記論理機能の連携動作をチェックするとき、前記安全制御モードが安全停止である場合、前記プロセッサは、異常を検出する機能を有する安全機能と、異常を検出する対象の主機能と、切替機能を有する安全機能との連携が前記論理アーキテクチャにおいて構築されているか否か判定する、車両制御システム検証装置。
  10. 　請求項８において、
    　前記論理アーキテクチャの論理機能は、前記車両制御システムにおいて所定の機能を実現するための主機能と、前記車両制御システムの異常に対応するための安全機能と、によって構成され、
    　前記論理機能の連携動作をチェックするとき、前記安全制御モードが機能継続である場合、前記プロセッサは、異常を検出する機能を有する安全機能と、異常を検出する対象の主機能と、代替制御を行う機能を有する安全機能と、切替機能を有する安全機能との連携が前記論理アーキテクチャにおいて構築されているか否か判定する、車両制御システム検証装置。
  11. 　請求項１に記載の車両制御システム検証装置を備え、
    　前記車両制御システム検証装置は、前記車両制御システムの物理アーキテクチャを構成する物理エレメントに配置され、
    　前記車両制御システム検証装置は、入力される、前記車両制御システムの前記論理アーキテクチャ及び前記物理アーキテクチャの情報と前記安全分析結果の情報とに基づいて、前記論理アーキテクチャが前記安全分析結果に対応する論理機能を有するか否かを検証する、車両制御システム。
  12. 　車両制御システムのアーキテクチャの安全性を検証するための車両制御システム検証方法であって、
    　プロセッサが、入力される、前記車両制御システムの論理アーキテクチャ及び物理アーキテクチャを取得することと、
    　前記プロセッサが、入力される、安全分析結果の情報を取得することと、
    　前記プロセッサが、少なくとも前記論理アーキテクチャの安全性を検証するためのプログラムを記憶デバイスから読み込み、前記安全分析結果の情報に基づいて、前記論理アーキテクチャが前記安全分析結果に対応する論理機能を有するか否かを検証することと、を含む、車両制御システム検証方法。
PCT/JP2017/015067 2016-04-28 2017-04-13 車両制御システム検証装置、車両制御システム、及び車両制御システム検証方法 WO2017187997A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
EP17789284.1A EP3451174B1 (en) 2016-04-28 2017-04-13 Vehicle control system verification device, vehicle control system, and vehicle control system verification method
US16/086,666 US11151076B2 (en) 2016-04-28 2017-04-13 Vehicle control system verification device, vehicle control system, and vehicle control system verification method
CN201780011147.2A CN109074299B (zh) 2016-04-28 2017-04-13 车辆控制系统验证装置、车辆控制系统以及车辆控制系统验证方法

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2016090200A JP6864992B2 (ja) 2016-04-28 2016-04-28 車両制御システム検証装置及び車両制御システム
JP2016-090200 2016-04-28

Publications (1)

Publication Number Publication Date
WO2017187997A1 true WO2017187997A1 (ja) 2017-11-02

Family

ID=60161666

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2017/015067 WO2017187997A1 (ja) 2016-04-28 2017-04-13 車両制御システム検証装置、車両制御システム、及び車両制御システム検証方法

Country Status (5)

Country Link
US (1) US11151076B2 (ja)
EP (1) EP3451174B1 (ja)
JP (1) JP6864992B2 (ja)
CN (1) CN109074299B (ja)
WO (1) WO2017187997A1 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115220421A (zh) * 2022-06-02 2022-10-21 智己汽车科技有限公司 一种自动驾驶系统在环的故障树分析和验证方法及设备
CN115220421B (zh) * 2022-06-02 2024-05-14 智己汽车科技有限公司 一种自动驾驶系统在环的故障树分析和验证方法及设备

Families Citing this family (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3279830B1 (en) * 2016-08-02 2020-10-28 Veoneer Sweden AB A vision system and method for a motor vehicle
DE102017010716A1 (de) * 2017-11-10 2019-05-16 Knorr-Bremse Systeme für Nutzfahrzeuge GmbH System zum wenigstens teilautonomen Betrieb eines Kraftfahrzeugs mit doppelter Redundanz
JP6979338B2 (ja) * 2017-11-20 2021-12-15 三菱航空機株式会社 配線構造の安全性評価システム
JP7028511B2 (ja) * 2018-04-25 2022-03-02 日本電気通信システム株式会社 車載用通信装置、車両内通信システム、通信方法及びプログラム
CN109885870A (zh) * 2019-01-09 2019-06-14 同济大学 一种用于自动驾驶汽车预期功能安全的验证方法及系统
CN111835627B (zh) * 2019-04-23 2022-04-26 华为技术有限公司 车载网关的通信方法、车载网关及智能车辆
CN111246422A (zh) * 2020-01-06 2020-06-05 新石器慧通（北京）科技有限公司 一种车载系统热启动切换方法
CN113377573A (zh) * 2020-03-10 2021-09-10 北京京东乾石科技有限公司 一种自动驾驶车辆的异常处理方法、装置、设备和存储介质
KR20210152125A (ko) * 2020-06-08 2021-12-15 주식회사 만도모빌리티솔루션즈 프로세스 검사 장치 및 방법과, 전자 제어 장치
EP4142189B1 (en) * 2020-09-23 2024-03-27 Bayerische Motoren Werke Aktiengesellschaft Determining correctness of actually received timestamp
CN112462731B (zh) * 2020-10-16 2022-06-24 北京西南交大盛阳科技股份有限公司 安全监督控制方法、安全监督控制装置、计算机设备及安全监督系统
CN112910850A (zh) * 2021-01-16 2021-06-04 浙江吉利控股集团有限公司 一种控制车辆的安全验证方法及系统
EP4087293A1 (en) * 2021-05-06 2022-11-09 Robert Bosch GmbH Methods and devices for radio communication
WO2023276569A1 (ja) * 2021-06-28 2023-01-05 株式会社デンソー 移動体の制御システム、プログラム
CN115150437B (zh) * 2022-09-01 2022-11-29 国汽智控(北京)科技有限公司 应用于车辆的自动驾驶系统的节点部署方法、装置及设备
CN115694707B (zh) * 2022-12-27 2023-04-11 北京理工大学深圳汽车研究院(电动车辆国家工程实验室深圳研究院) 一种基于业务识别的汽车区系统及实时同步调度方法

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007506591A (ja) * 2003-06-24 2007-03-22 ローベルト ボッシュ ゲゼルシャフト ミット ベシュレンクテル ハフツング ソフトウェアベースの電子システムの安全性と信頼性を検査する方法
JP2012008744A (ja) * 2010-06-23 2012-01-12 Inst Nuclear Energy Research Rocaec 原子力発電プラント用コンピュータ支援トップ論理によるリスクの定量的評価方法。

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6892317B1 (en) * 1999-12-16 2005-05-10 Xerox Corporation Systems and methods for failure prediction, diagnosis and remediation using data acquisition and feedback for a distributed electronic system
ATE511669T1 (de) 2004-01-13 2011-06-15 Renault Sas Entwurf von sicherheitskritischen systemen
WO2007000007A1 (en) * 2005-06-28 2007-01-04 Tttech Computertechnik Aktiengesellschaft Safe start-up of a network
ATE485527T1 (de) * 2007-02-16 2010-11-15 Freescale Semiconductor Inc System und rechnerprogrammprodukt zum testen einer logischen schaltung
US20090012631A1 (en) * 2007-07-03 2009-01-08 Dale Fuller Automation safety life cycle
US8060347B2 (en) * 2008-07-29 2011-11-15 Mentor Graphics Corporation Complexity management for vehicle electrical/electronic architecture design
CN102169458A (zh) * 2011-04-18 2011-08-31 华东师范大学 汽车电控部件的软件正确性验证系统及其验证方法
US9058419B2 (en) * 2012-03-14 2015-06-16 GM Global Technology Operations LLC System and method for verifying the integrity of a safety-critical vehicle control system
DE102012215343A1 (de) * 2012-08-29 2014-05-28 Continental Automotive Gmbh Verfahren zum Durchführen einer Sicherheitsfunktion eines Fahrzeugs und System zum Durchführen des Verfahrens
US10180995B2 (en) * 2013-07-15 2019-01-15 The Boeing Company System and method for assessing cumulative effects of a failure
JP6066081B2 (ja) * 2013-09-03 2017-01-25 インターナショナル・ビジネス・マシーンズ・コーポレーションＩｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓ Ｃｏｒｐｏｒａｔｉｏｎ フォールトツリーを生成する装置及び方法
US9195232B1 (en) * 2014-02-05 2015-11-24 Google Inc. Methods and systems for compensating for common failures in fail operational systems
US20170147459A1 (en) * 2014-04-16 2017-05-25 Nec Corporation Availability analysis device, availability analysis method, and recording medium having availability analysis program recorded therein
US10061670B2 (en) * 2015-12-28 2018-08-28 Siemens Aktiengesellschaft Method and apparatus for automatically generating a component fault tree of a safety-critical system

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007506591A (ja) * 2003-06-24 2007-03-22 ローベルト ボッシュ ゲゼルシャフト ミット ベシュレンクテル ハフツング ソフトウェアベースの電子システムの安全性と信頼性を検査する方法
JP2012008744A (ja) * 2010-06-23 2012-01-12 Inst Nuclear Energy Research Rocaec 原子力発電プラント用コンピュータ支援トップ論理によるリスクの定量的評価方法。

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP3451174A4 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115220421A (zh) * 2022-06-02 2022-10-21 智己汽车科技有限公司 一种自动驾驶系统在环的故障树分析和验证方法及设备
CN115220421B (zh) * 2022-06-02 2024-05-14 智己汽车科技有限公司 一种自动驾驶系统在环的故障树分析和验证方法及设备

Also Published As

Publication number Publication date
JP2017199229A (ja) 2017-11-02
CN109074299A (zh) 2018-12-21
US20190108160A1 (en) 2019-04-11
EP3451174B1 (en) 2022-08-10
EP3451174A1 (en) 2019-03-06
JP6864992B2 (ja) 2021-04-28
US11151076B2 (en) 2021-10-19
CN109074299B (zh) 2021-12-14
EP3451174A4 (en) 2019-12-18

Similar Documents

Publication Publication Date Title
WO2017187997A1 (ja) 車両制御システム検証装置、車両制御システム、及び車両制御システム検証方法
US20190312892A1 (en) Onboard cybersecurity diagnostic system for vehicle, electronic control unit, and operating method thereof
US11107300B2 (en) Driving management system, vehicle, and information processing method
US10459446B2 (en) Autonomous operation verification device and autonomous system
CN106458112A (zh) 更新管理方法、更新管理装置以及控制程序
JP5319534B2 (ja) 障害管理方法、および障害管理のための装置
JP2009250693A (ja) 故障診断用情報生成装置及びシステム
KR20190119514A (ko) 차량용 온보드 사이버보안진단 시스템, 전자 제어 장치 및 그것의 동작 방법
CN102713858A (zh) 信息处理装置的联机调试系统及联机调试方法
CN108810850A (zh) 车载故障播报系统、方法、设备及存储介质
SE541828C2 (en) Method and control arrangement for prediction of malfunction of a wheel bearing unit of an axle in a vehicle
JP2014031077A (ja) 車両動作検証システム
JP5682388B2 (ja) 障害診断方法及び障害診断システム
US11372442B2 (en) Vehicle control system validation technique and validation device, and control device
KR20200058194A (ko) 차량의 v2x 검사 단말기 및 그 방법
WO2023272570A1 (zh) 电子控制单元ecu更新的方法、ecu和终端
CN109828857A (zh) 车辆故障原因定位方法、装置、设备和存储介质
CN106414214A (zh) 具有任务冗余和非对称通信能力的铁路安全关键系统
CN115384536A (zh) 一种驾驶辅助系统控制器的评估方法、装置、设备及介质
Harris Embedded software for automotive applications
CN112667671B (zh) 一种路网数据处理方法、装置、计算机设备和存储介质
CN115946673B (zh) 一种汽车制动的故障诊断方法、系统、设备和介质
JP7204471B2 (ja) 車両用電子制御装置、異常信号生成方法、異常信号生成プログラム
JP6407836B2 (ja) 適応データ出力装置
US20210061285A1 (en) Method for generating a reference representation

Legal Events

Date Code Title Description
NENP Non-entry into the national phase

Ref country code: DE

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17789284

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2017789284

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 2017789284

Country of ref document: EP

Effective date: 20181128