ISO 20077-1:2017 道路車両—拡張車両（ExVe）方法論—パート1：一般情報 | ページ 6

3.1

diagnosis

result of a diagnostic process (3.2) carried out on a vehicle

3.2

diagnostics

diagnostic process

process including the detection process of possible vehicle malfunctions (3.10) , the identification of the likely root cause of these malfunctions and the appraisal of its relevance for the operation of the vehicle

3.3

diagnostics step 1

detection process of possible vehicle malfunctions (3.10)

Note 1 to entry: The detection process of possible vehicle malfunctions (diagnostics step 1) may lead to the conclusion of an absence of malfunction.

3.4

diagnostics step 2

identification of the likely root cause of malfunctions (3.10)

Note 1 to entry: Root cause analysis (diagnostics step 2) is only performed in presence of a malfunction. Root cause analysis is performed if diagnostics step 1 has been performed.

3.5

extended vehicle

entity, still in accordance with the specifications of the vehicle manufacturer (3.20) , that extends beyond the physical boundaries of the road vehicle and consists of the road vehicle, off-board systems (3.11) , external interfaces and the data communication between the road vehicle and the off-board systems

Note 1 to entry: Road vehicles without off-board systems and road vehicles equipped with telematics units are extended vehicles.

3.6

ExVe manufacturer

vehicle manufacturer (3.20) responsible for the extended vehicle (3.5)

3.7

function

task, action or activity that should be achieved to satisfy a functional requirement

Note 1 to entry: The same function may be used in several different use cases (3.17) .

3.8

functionality

set of functions (3.7) that ensures the overall capability of the system to satisfy a functional requirement (3.9)

Note 1 to entry: In the set of functions necessary for “establishing the communication with an extended vehicle”, one can find such functions as “KEY ON-ENGINE OFF”, etc.

Note 2 to entry: The same functionality may be used in several different use cases (3.17) .

3.9

functional requirement

<extended vehicles> statement issued by the vehicle manufacturer (3.20) that identifies what a product or process must accomplish to produce required behaviour and/or results

Note 1 to entry: The functional requirement is issued by the body in charge of the design of the product or process.

[SOURCE:ISO/IEC/IEEE 24765:2010, 3.1229, definition 1, modified — source entry has been modified to introduce that, in the case of extended vehicles, the statement is issued by the vehicle manufacturer and Note 1 has been added to source entry.]

3.10

malfunction

state of a system or a component that deviates from the specifications of the vehicle manufacturer (3.20)

Note 1 to entry: A malfunction may be the object of an alert on board the vehicle and possibly lead to a DTC, but a malfunction does not necessarily preclude a DTC.

Note 2 to entry: A slight deterioration of a system, such as the normal wear of that system, is not a malfunction as long as it does not impair the performance of that system against the design specifications of the vehicle manufacturer.

3.11

off-board system

<road vehicles> software and hardware components off-board a road vehicle that have been specified, designed, developed and/or manufactured to address the requested functionalities (3.8)

3.12

prognosis

prediction which is the result of a prognostic process (3.13)

3.13

prognostics

prognostic process

<automotive> process of forecasting the possible occurrence of vehicle malfunctions (3.10) and appraising the likely remaining operation time of the vehicle until these malfunctions occur

Note 1 to entry: A prognostic process cannot be performed without having performed the detection process of possible malfunctions of the same functionally related system [ diagnostics step 1 (3.3) ].

Note 2 to entry: A diagnostic process (3.2) may be performed without performing a prognostic process (for example, in the case of the presence of a malfunction, when diagnostics step 2 (3.4) is performed).

3.14

remote , adjective

performed on a vehicle from a distance where the operator responsible for the concerned operation is not co-located with the vehicle and where the vehicle is connected via an external network

Note 1 to entry: The “operator responsible for the concerned operation” is a specific actor in terms of use case (3.17) .

3.15

remote diagnostician

remote diagnostics operator

physical person that performs a remote diagnostic process

3.16

remote diagnostic support

information provided to a remote diagnostician (3.15) to assist in the performance of the remote diagnostic process of a vehicle

Note 2 to entry: Diagnostic support that is provided for performing conventional diagnostics is the foundation for remote diagnostic support (the access to that information in the case of conventional diagnostics is standardized in ISO 18541-1).

3.17

use case

sequence of interactions between one or several actors and the concerned system, which has a defined goal and provides a measurable result

Note 1 to entry: “Read all active DTCs” may be comprised of the following interactions: initialization of the communication, identification of the vehicle, sending the request to get DTC information (“read DTC”), receiving DTC information, terminating of the communication.

Note 2 to entry: Actors may be both human and machines.

Note 3 to entry: In the case of an extended vehicle (3.5) , the concerned system is the extended vehicle itself.

Note 4 to entry: In order to be able to perform the design of an extended vehicle, it is necessary that the use cases are completed by the appropriate use case scenarios and use case functional requirements.

3.18

use case cluster

<road vehicles> grouping of use cases (3.17) that together have the same goal measurable result

Note 1 to entry: Use case clusters may be themselves regrouped into areas, the typology of which may generate different types of technical solutions, although some solutions may be common to several areas.

Note 2 to entry: Extended vehicles have been developed to be used in all the use case clusters areas where vehicle connectivity is expected, for example, cooperative ITS, fleet management, remote diagnostic, car sharing, etc.

3.19

use case scenario

set of circumstances under which the sequence of interaction describing a use case (3.17) takes place

Note 1 to entry: The same use case may take place under different scenarios, but the sequence of interaction may also be affected by the circumstances. In that case, one would have more than one use case.

Note 2 to entry: In the case of an operation performed on an immobilized vehicle, the presence or absence of a technician may be part of the use case scenario.

3.20

vehicle manufacturer

person or body who is responsible to the approval authority for all aspects of the type approval or authorization process and for ensuring conformity of production of a vehicle

Note 1 to entry: It is not essential that the person or body be directly involved in all stages of the construction of the vehicle, system, component or separate technical unit which is the subject of the approval process.

Note 2 to entry: Adapted from Directive 2007/46/EC.

[SOURCE:ISO 18541‑1:2014, 3.1.46]

3.21

web service

software system, with an interface described in a machine-processable format and designed to support interoperable machine-to-machine interaction over a network

[SOURCE:WORLD WIDE WEB Consortium Glossary - W3C Working Group Note 11 - February 2004, modified — source entry has been modified not to restrict the concept to one protocol or one type of messages and to partly include Note 1 to source entry and Note 2 to source entry has been disregarded.]