This part of the ISO 15638 family of standards deliverables provides specifications for generic basic vehicle data [4.4] that it is required for all IVSs to support and make available t
General overview
Context
ISO 15638-1 provides a framework and architecture for TARV It provided a general description of the roles of the actors in TARV and their relationships
Figure 1 shows the role model conceptual architecture showing the key actors and their relationships
Re por ts Fe es
Figure 1 — Role model conceptual architecture
To understand more clearly the TARV framework in detail the reader is referred to ISO 15638-1
ISO 15638 outlines a comprehensive set of standards for cooperative telematics applications in regulated commercial freight vehicles, focusing on areas such as access monitoring, driver fatigue management, speed monitoring, on-board mass monitoring, and charging The standard encompasses operational concepts, legal and regulatory considerations, and a generic cooperative ITS service platform It adopts a service provider-oriented approach, detailing provisions for the approval and auditing of service providers by the relevant authorities.
ISO 15638 is comprised of seven framework parts and twelve application specific parts The framework parts are:
Part 2: Common platform parameters using CALM
Part 3: Operating requirements, 'Approval Authority' procedures, and enforcement provisions for the
Part 6: Regulated applications [Technical Specification]
Many application services, both regulated and commercial, have unique data requirements from the IVS or connected equipment However, there is a set of generic data that is essential for most, if not all, application services related to regulated commercial vehicles.
All Intelligent Vehicle Systems (IVSs) must support the basic vehicle data outlined in the ISO 15638 suite of standards, regardless of the specific functionality or physical design, which is determined by market regulations and jurisdictions.
(for example, shall have a unique identifier, collect time and location data, etc.)
Certain data concepts, although not universally necessary for every TARV in all jurisdictions, may be essential for all equipment or specific classes of TARVs within a jurisdiction to ensure effective regulation Many of these frequently required data concepts are defined in this section of ISO 15638 to promote interoperability.
Core application data for a specific jurisdiction consists of basic vehicle data and additional data concepts relevant to that jurisdiction or class of TARVs Basic vehicle data is universally present in all equipped TARVs, while core application data is specific to equipped TARVs within that jurisdiction.
Internationally operating equipped vehicles must carry all necessary data concepts required by the jurisdictions in which they operate to ascertain their core application data By establishing standard definitions for these commonly expected additional data concepts, achieving international interoperability becomes straightforward.
This part (15638-5) provides definition for generic vehicle information, and simple means for authorised actors to download that information This information comprises:
basic vehicle data [4.4] provided by the TARV LDT [4.10]* for TARV applications (local data tree [4.10]);
basic vehicle data [4.4] provided by the C-ITS LDT [4.10] * for cooperative intelligent transport systems (particularly cooperative safety related systems);
core application data [4.5] which comprises basic vehicle data [4.4] (from the TARV LDT [4.10])together with additional data requirements in a particular jurisdiction [4.9] ;
Archive data, which enables the prime service provider [4.15] to maintain a complete record of data calculated and recorded on-board
The Local Data Tree (LDT) is a crucial data concept stored in the on-board data pantry, comprising essential data values for TARV regulated applications and cooperative intelligent transport systems.
ISO 15638-1 acknowledges that various jurisdictions have unique requirements, which may necessitate additional data beyond the basic vehicle information This combination of basic vehicle data and supplementary information is referred to as core application data, or 'CoreData,' within the ISO 15638 framework.
In the context of global TARV, transcontinental journeys, such as traveling from the UK to Russia through multiple countries or from China to Malaysia, cannot solely depend on users or application service providers to possess and supply the necessary data to comply with the diverse legal requirements of all jurisdictions involved.
[4.9] of all of the transit countries, particularly as such requirements may also vary over time and from freight type to freight type
Certain data stored in the vehicle is commercially sensitive, necessitating protective measures to prevent unauthorized access and misuse.
In a co-operative Intelligent Transportation Systems (ITS) environment, data should not be limited to single data concepts like basic vehicle data or core application data While grouping data elements into these categories is acceptable, it is inefficient to restrict their availability solely within these defined concepts Instead, leveraging data from various onboard applications can enhance efficiency and functionality.
To ensure security and interoperability across all cooperative ITS systems, it is essential to implement a unified and secure approach that facilitates common use and data reuse.
The on-board data library calculates and stores discrete data concept values in the 'data pantry', with update frequency determined by the app According to ISO 15638, additional apps in the library compile this data into two key concepts: a) TARV LDT [4.10] values and b) C-ITS LDT [4.10] values.
A further app creates an archive of the history and values of data, stored in a file called ‘RecentArchive’
6.1.1.2 Data creation process and architecture
Ad ISO 15638 data creation and storage process v12
Execution environment performs loaded Apps
Jurisdiction requests core application data
LDT data concept values updated in data pantry
Data concept values updated in data pantry
Execution environment updates BasicVehicleData values
Execution environment updates CoreApplicaton Data values
Execution environment provides TARV LDT
Execution environment provides (already frequently updated) C-ITS LDT
Safety App requests C-ITS LDT
Execution environment updates TARV LDT
Apps library App 1 App 2 App 3
Execution environment provides CoreApplicaton Data values
Figure 2 illustrates the process of apps being uploaded to the app library, where the execution environment runs the apps and updates the data concept values in the data pantry It highlights the updating of LDT [4.10] values according to the instructions of the relevant app Additionally, a jurisdiction [4.9] uploads an app for its core application data [4.5], prompting the necessary updates to the core application data concept values Once updated, the jurisdiction requests the core application data values, which are then provided.
An example of an application utilizing the TARV LDT is presented, where the app in the execution environment triggers a refresh of the TARV LDT values and subsequently provides them to the application.
ROAM
The ROAM (Regime for Open Application Management) architecture establishes a framework and operational environment for the development and deployment of TARV applications, aligning with the cooperative intelligent transport telematics systems as defined in ISO 15638-1.
ROAM provides an open execution environment in which TARV applications can be developed, delivered, implemented and maintained during the life cycle of both service applications and equipment
TARV applications for regulated commercial vehicles can be implemented according to the regulations of implementing jurisdictions [4.9], and at their discretion, via an app provided by the jurisdiction
ISO 15638-6 offers a set of generic and interoperable regulated application services, serving as a toolbox for jurisdictions Additionally, ISO 15638-7 outlines the methodology to support commercial services for TARVs and facilitates cooperation and interoperability with general safety services across all vehicle classes.
In the TARV environment, regulated applications are developed by jurisdictions and deployed by application service providers to Host Management Centres (HMC) The HMC acts as a service gateway, ensuring the secure delivery of software and services for TARVs It manages the provisioning of applications to authorized users through its client system, allowing for the execution of the application once properly installed Flexible software deployment and management are facilitated by JAVA™ and OSGi™, with the framework and architecture being well-established in other sectors, including mobile telephony.
Regulated commercial vehicles have specific requirements that differ across jurisdictions However, equipped TARVs function within cooperative ITS systems and do not operate in isolation The on-board platform for TARV regulated application services also facilitates additional commercial services and supports general cooperative safety services for all vehicle classes.
ROAM establishes a versatile architecture utilizing CVIS/OSGi ™ that integrates in-vehicle systems, roadside infrastructure, and essential back-end systems for the cooperative management of transport safety and efficiency This architecture is designed to be implementation-independent, enabling the use of diverse client and back-end server technologies.
TARV-ROAM is therefore a specific instantiation of a common approach for secure data provision in a cooperative ITS environment, adapted to the needs of TARV
While the reader is referred to ISO 15638-1 for an explanation of the architecture and functioning of TARV-
ROAM, the following Figures are reproduced as a reference précis
Figure 3 illustrates TARV service provision with ROAM Identified
Figure 3 — TARV service provision with ROAM identified
Figure 4 provides a view of the IVS component disposition id
Gateway_VehicleDatabus Gateway_OtherEquip/Sensors
Figure 4 — TARV IVS component decomposition
Figure 5 provides a view of the communications
Ud TARV ROAM vehicle and roadside system related use cases
Host Management Centre (HMC) CooperativeITSApplications
Figure 5 — UML representation of TARV-ROAM communication diagram
Figure 6 shows a UML view of TARV–ROAM service platform components
Id 15638-5 TARV-ROAM Service Platform Components
Local Device Tree Distributed Directory
6.1.2.2 TARV supported o LDT [4.10] basic vehicle data [4.4] concepts
2) C-ITS LDT asic vehicle data [4.4] is focussed to the specific requirements for regulated commercial ehicles
Cooperative Intelligent Transport Systems (C-ITS) are designed to meet the requirements for all vehicle classes, emphasizing safety applications The basic vehicle data plays a crucial role in representing the C-ITS local data tree.
This version of TARV supports tw
Figure 7 — C-ITS local data tree
Figure 8 shows the TARV local data tree [4.10]
Date Timestamp Breakdown ACC EBM Crash Temperature
Intensity Rain Wipers Lights Speed
Time and Timestamp Data Control
No of satellites present Direction
Figure 8 — TARV local data tree
Communications requirements
TARV-ROAM communications layers shall conform to ISO 15638-2.
TARV-ROAM Security requirements
TARV-ROAM security aspects shall conform to ISO 15638-4.
TARV-ROAM facilities layer requirements
TARV-ROAM facilities layer functions shall conform to:
ETSI TS 102 894 Intelligent Transport System (ITS); Users & Applications requirements; Facility layer structure, functional requirements and specifications
ETSI TS 102 890-1 Intelligent Transport Systems (ITS); Facilities layer function; Communication management specification
ETSI TS 102 890-2 Intelligent Transport Systems (ITS); Facilities layer function; Services announcement specification
Any TARV-ROAM local dynamic map specifications shall conform to EN 302 895 ‘Intelligent Transport
Systems (ITS);Vehicular Communications;Basic Set of Applications; Local Dynamic Map (LDM) Specification’
7.4 7Host management centre (HMC) requirements
The HMC will function in accordance with the essential Java bundle that incorporates a management agent, alongside the CVIS process designed to automate and secure operations Additional Java classes relevant to this implementation can be accessed through the provided documentation links.
Data provision
Location of on-board data
On-board data calculated or obtained by the IVS shall be stored as individual data concept values in the ‘data pantry’ defined in ISO 15638-1
Apps shall be provided by the prime service provider [4.15], application service [4.2] providers and jurisdictions
The IVS will store data in non-volatile memory within an 'application library', where its function is determined by product design rather than standardization.
The’ Host Management Centre’/execution environment shall host and run the apps
TARV data will be computed by applications within the on-board data library and saved as distinct data concept values in the 'data pantry.' The frequency of these updates is set by the application itself.
The means by which data is collected shall be at the determination of the prime service provider [4.15], but shall be capable to meet the relevant requirements of 8.3
The specifications shown in this part of ISO 15638 are shown below in semantic representation Data presentation shall be as determined in ISO 15638-2 (Common platform parameters using CALM)
The actual position of an element within the data stream is determined by the ASN1 definition, which must be detailed by the relevant jurisdiction or its representative, in accordance with ISO 15638-2.
Example ASN.1 definitions may be provided in ISO 15638-6 and ISO 15638-7
It should therefore be noted that data elements therefore do not necessarily start or end on a byte boundary.
Naming of ‘Apps’
An ‘App’ is created by or to the instruction of a jurisdiction [4.9] to obtain data from the vehicle (CoreData)
The App name shall always be the IPv6 address of the destination that the data creates is to be sent
IPv6 addresses ensure uniqueness, allowing multiple applications to be sent to the on-board apps library by different parties without the risk of naming conflicts This capability enables safe storage of various apps, even when the senders are unaware of each other.
It also provides additional security for CoreData over and above that provided by ISO 15638-4.
Local data trees
Additional apps in the library shall be provided by the prime service provider [4.15] and shall collate the data into two collated data concepts: a) TARV LDT values b) C-ITS LDT values
C-ITS LDT
The C-ITS (Co-operative Intelligent Transport Systems) LDT emphasizes the essential vehicle data required for cooperative intelligent transport systems across all vehicle classes, prioritizing safety applications.
To ensure the interoperability and effective functioning of cooperative safety services, such as collision avoidance and alerts for ice, fog, and obstacles, it is essential that all vehicles, regardless of class, share the same basic vehicle data.
The data content of the C-ITS LDT [4.10] shall therefore be as determined in a future standard to be developed by ISO or ETSI
Apps from the onboard Apps library will update the data concepts in the 'data pantry' and the C-ITS-LDT at specified frequencies or as determined by the app If not predetermined by the standard, the app installed by the prime service provider will dictate how and when the data is populated and refreshed While this part of ISO 15638 does not specify these details, it does state that the data format and access rights will be defined in ISO 15638-4 and a future standard from ISO or ETSI regarding the final data payload of the C-ITS LDT.
TARV LDT
The TARV LDT [4.10] is focussed on the specific requirements for the provision of application services to regulated commercial vehicles
TARV LDT [4.10] basic vehicle data [4.4] shall consist of at least the data specified in Clauses 8.3 and stored in the ‘data pantry’ in formats specified in these subClauses
This section aims to define the essential basic vehicle data required for application service providers, which will be supported by in-vehicle systems for cooperative telematics applications in regulated commercial freight vehicles The data will be represented in the TARV LDT, with specifications outlined in section 8.3 and the organization of the TARV LDT detailed in section 8.4.
Many application services, whether regulated or commercial, have unique data requirements from the IVS or connected equipment However, there is a set of generic data that is essential for most, if not all, TARV application services This includes basic vehicle data, as outlined in the C-ITS-LDT, which is crucial for safety and cooperative intelligent transport systems across all vehicle classes.
The ISO 15638 suite of standards provides essential generic information known as 'TARV basic vehicle data,' which is crucial for the implementation of Intelligent Vehicle Systems (IVS) While the design of IVS functionality and physical form is influenced by market and jurisdictional regulations, the foundational data remains a key component in ensuring compliance and effectiveness.
[4.4] ’, shall be supported by all TARV IVSs:
(for example, shall have a unique identifier, collect time and location data, etc.)
Apps from the on board apps library shall update the data concepts in the ‘data pantry’ and the TARV-LDT
The frequencies for data population and refreshment, as specified in ISO 15638, or determined by the app, will be established by the prime service provider or application service provider The data format stored in the data pantry is defined in Clause 8, while access rights are outlined in ISO 15638-4 Additionally, the app will set the IPv6 destination address for the prime service provider and application service providers to receive data, and for core application data, the apps will be designated as the destination address.
The prime service provider, application service providers, and jurisdictions can introduce new applications to the IVS app library using the methods outlined in ISO 15638-1 and ISO 15638-5, along with their referenced standards.
ISO 15638 specifies the essential basic vehicle data required for all TARV IVS systems to support and provide to application service providers through a wireless communication link This facilitates the delivery of both regulated and commercial application services, utilizing the TARV local data tree (LDT).
Certain data concepts, while not universally necessary for every TARV in all jurisdictions, may be essential for all equipment or specific classes of TARVs within a jurisdiction to ensure effective regulation These frequently required data concepts are defined in Clause 9 of ISO 15638 to facilitate interoperability and establish the core application data concept.
Recent data archive
A further app shall be provided by the prime service provider [4.15] and shall create an archive of the history and values of data, stored in a file called ‘RecentArchive’.
Commands for vehicle data
GET TARV LDT data
Upon receiving the command 'GETTARVLDT', the system will deliver the TARV LDT data values along with the specified destination address to the previously designated application service provider or jurisdiction Data will not be sent to any other destination, and the IVS will not provide information to addresses submitted concurrently with the data request Instead, data will only be sent to pre-established addresses Following this, the system will send an acknowledgment (ACK) to the requesting address and promptly terminate the communication.
By directing responses solely to a specified IPv6 address, the risk of phishing and unauthorized access to data is greatly minimized.
GET C-ITS LDT data
Upon receiving the command 'GETC-ITSLDT', the system will provide authorized users with the values of the C-ITS LDT data concept as outlined in ISO 15638 These values will be sent to the previously specified destination address of the requesting application service provider or jurisdiction.
Data will only be sent to predetermined addresses and cannot be directed to any other destination Requests for data must not include a destination address, as the IVS is prohibited from sending data to addresses provided at the time of the request.
CREATE core application data
To generate core application data, the IVS must first create it Although there is a single command for this process, multiple applications may run concurrently in the vehicle, each with distinct core application data.
The application therefore first provides the IVS system with the destination IPv6 for the core application data
It then provides the command ‘CREATECoreData’
Upon receiving the 'CREATECoreData' command, the system will execute the corresponding 'app' that matches the destination IPv6 address This process will populate the core application data with the current values of the TARV LDT, along with any additional data specified in the 'app' Furthermore, upon request for CoreData, the system will supply the values to the designated address of the requesting application service provider or jurisdiction, as outlined in the previously uploaded 'app'.
Data will only be sent to a specified IPv6 address programmed into the provided application, rather than being returned to the inquirer's address The core application data includes the TARV LDT data and any required or supported regulated application service data for TARV, along with the destination IPv6 address (app filename).
Figure 9 shows an example For explanation of the detail of the content see clauses 8.3, 8.4 and 9 below
ISO 15638 specifies that sections 8.3.1 to 8.3.17 outline the essential vehicle data required for all Intelligent Vehicle Systems (IVS) used in regulated commercial vehicles across various jurisdictions However, individual jurisdictions may impose further requirements for additional data beyond the basic specifications, depending on the regulated application services they support Clause 9 of this standard offers potential candidates for these additional data requirements.
The use of all or any of these candidates in additional to the TARV LDT [4.10] to form the core application data
[4.5] is at the election of the jurisdiction [4.9]
The purpose of defining these additional data concepts is to provide international interoperability so that where used, they are used consistently
The core application data [4.5] represents a transient data concept that is populated based on the most recent usage Understanding this singular data concept is crucial for effective data management.
‘CREATE Core application data’ command This both keeps the application programming simple and uses the limited memory of the IVS efficiently.
GET core application data
Upon receiving the 'GETCoreData' command, the system will transmit the values of the core application data that have recently been provisioned into the CoreData.
The 'CREATECoreData' command, along with the specified destination address from the requestor, directs data exclusively to the predetermined IPv6 address of the application service provider or jurisdiction Under no circumstances will the IVS provide data directly to an interrogating party; it will only send data to the previously established IPv6 address associated with the provisioned application After sending the data, the system will acknowledge the request by sending an ACK to the requesting address and will promptly terminate the communication with that address.
To prevent unauthorized access to vehicle data through spoofing, phishing, or other fraudulent methods, core application data can only be retrieved using the "GETCoreData" command, which transmits information exclusively to a predetermined IPv6 address Additional security measures established by TARV-ROAM and ISO 15638-4 ensure that unauthorized applications cannot be loaded into the on-board app library Consequently, even if a spoof application service provider successfully connects to the IVS, any attempt to access core application data will only direct the information to its legitimate destination, safeguarding against data breaches.
GET Archive
Upon receiving the 'GETArchive' command, the system will deliver the contents of the 'RecentArchive' file from the non-volatile memory of the IVS to the designated IPv6 address provided by the prime service provider Access to the 'RecentArchive' file is restricted to the application or prime service provider using the previously supplied IPv6 address, ensuring protection against unauthorized access by any other parties, except during maintenance operations conducted by the prime service provider or their agent It is prohibited to specify a destination address when requesting data, as the IVS will only transmit data to pre-established addresses, never to those provided concurrently with the data request.
Upon successfully receiving the 'RecentArchive' data, the prime service provider will send an acknowledgment (ACK) to the IVS, confirming receipt of the data in accordance with the format specified in ISO 15638-3.
Upon receiving the ACK, the IVS will clear the 'RecentArchive' file and begin repopulating it with a record of the file clearance in the format yyyymmddhhmmss.
Presentation of the ‘basic vehicle data’ concept
Data format version
The ‘data pantry’ of the IVS shall:
The data format must include a version identification that consists of a three-letter country code, as specified by ISO 3166-1, which defines the representation of country names and their subdivisions.
The article discusses the identification of states or subdivisions within a jurisdiction, utilizing a two-letter code as defined by ISO 3166-2 This standard outlines the representation of country names and their subdivisions, allowing jurisdictions to determine appropriate codes for their specific subdivisions.
• followed by a sequential version number starting from version 1 to discriminate from later TARV data formats for that jurisdiction [4.9]
• Where there is no subpartition the element may be omitted
EXAMPLES AUSVA1 USACA2 GB1 NL4
(Australia Victoria version 1) (USA California version 2) (Great Britain version 1) (Netherlands version 4)
Later versions shall be backwards compatible with existing versions
Systems that process TARV-regulated commercial freight vehicle data must be compatible with all standardized TARV versions applicable in their jurisdiction Each version is uniquely identified by the TARV data format version parameter, which is specified to be included in the first byte of all current and future TARV LDT data concepts.
Message identifier
The ‘data pantry’ of the IVS shall carry a message identifier, starting with 1, incremented for each repeated
TARV LDT [4.10] data transfer attempt until the receipt of the data concept is acknowledged upon which the message identifier reverts to 1
The IVS's 'data pantry' will store the IPv6 address of the primary service provider, facilitating the establishment of communication sessions with the provider as needed.
The data shall be stored in the format:
As PSP xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx
The standard format for an IPv6 address is represented as xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx, where each 'x' is a hexadecimal digit that corresponds to 4 bits IPv6 addresses can range from 0000:0000:0000:0000:0000:0000:0000:0000 to ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff.
An alternative format for IPv6 addresses integrates colon and dotted notation, allowing an IPv4 address to be embedded within the IPv6 address In this format, the left-most 96 bits are represented in hexadecimal, while the right-most 32 bits indicate the embedded IPv4 address in decimal This approach guarantees compatibility between IPv6 and IPv4 nodes, facilitating operations in mixed network environments.
These two types of IPv6 addresses use this alternative format:
IPv4-mapped IPv6 addresses enable direct communication between IPv6 and IPv4 applications These addresses are represented in formats such as 0:0:0:0:0:ffff:192.1.56.10 and the shortened version ::ffff:192.1.56.10/96.
This type of address is used for tunnelling It allows IPv6 nodes to communicate across an IPv4 infrastructure For example, 0:0:0:0:0:0:192.1.56.10 and ::192.1.56.10/96 (shortened format).
Application service provider identifier
The IVS's 'data pantry' will store the IPv6 addresses for all application services subscribed by the user, facilitating the establishment of communication sessions with the relevant service providers.
In order to identify the particular application service, the identifier shall additionally provide an application service [4.2] programme identifier in addition to the IPv6 address of the application serviceprovider
The application service [4.2] program identifier shall be stored in the format specified by IEEE 1609 (ITS AID addressing)
ITSaid1ext::=CHOICE{ content [0] INTEGER(128 16511), contained in two octets of ITSaid extension [1] ITSaid2ext
} and shall use API’s issued by an international registration authority
APIs for generic regulated application services [4.13] shall be obtained and issued via provisions made in ISO 15638-6
Application service providers must register their services with the registration authority and obtain a unique API for each application service.
The data shall be stored in the format:
As AS 00000000 00000000xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx
Session control data
Shall be presented as specified in ISO 15628-2 (TARV- Common platform parameters using CALM) and the media appropriate CALM Media standard(s)
The CALM media standards at the time of development of this part of ISO 15638 are:
ISO 21210 Intelligent transport systems — Communications access for land mobiles — IPv6 Networking
ISO 21212 Intelligent transport systems Communications access for land mobiles (CALM) 2G Cellular systems
ISO 21214 Intelligent transport systems Communications access for land mobiles (CALM) Infra-red systems
ISO 21215 Intelligent transport systems Communications access for land mobiles (CALM) M5
ISO 21216 Intelligent transport systems Wireless communications CALM using millimetre communications Air interface
ISO 21217 Intelligent transport systems Communications access for land mobiles (CALM) – Architecture
ISO 21218 Intelligent transport systems Communications access for land mobiles (CALM) Medium service access points
ISO 25111 Intelligent transport systems Communications access for land mobiles (CALM) General requirements for using public networks
ISO 25112 Intelligent transport systems Communications access for land mobiles (CALM) Mobile wireless broadband using IEEE 802.16
ISO 25113 (CALM) Mobile wireless broadband using HC-SDMA
ISO 29281 Intelligent transport systems Communications access for land mobiles (CALM) Non-IP networking
ISO 29282 Intelligent transport systems Communications access for land mobiles (CALM) Applications using satellite networks
ISO 29283 ITS CALM Mobile Wireless Broadband applications using Communications in accordance with
ISO 13183 Intelligent transport systems — Communications access for land mobiles (CALM) — Broadcast communications
Vehicle unique identifier
The IVS of regulated commercial freight vehicles will maintain a unique vehicle identification within its 'data pantry.' The prime service provider is responsible for programming the IVS with a file that includes the vehicle registration number, as specified in ISO 14816, which outlines the automatic vehicle identification numbering and data structure, particularly in Clause 4.10 regarding vehicle license coding.
Vehicle class identification
The 'data pantry' of the IVS for regulated commercial freight vehicles must include a vehicle class identification, developed in accordance with ISO 17262 or ISO 26683-2, or based on the specific vehicle classification defined by the relevant jurisdiction.
VIN number
The IVS's data pantry for regulated commercial freight vehicles must include the Vehicle Identification Number (VIN), as specified by ISO 3779, which outlines the content and structure of VINs for road vehicles.
1st-3rd digit - World Manufacturer Indicator, ISO 3780 Who made the vehicle
4th-8th digit - Manufacturer Specific Model of vehicle, engine, bodystyle, etc
9th digit - Check digit Mathematical Formula to determine if VIN is real
10th digit – Year Model year of the vehicle
11th digit - Assembly Plant - Manufacturer Specific The assembly plant that built the car
12th - 17th digit - Sequence Number Usually starts at 100001,200002,A0000A, B0000B, etc
See ISO 24534 for VIN variant provisions
Propulsion storage type
The IVS's 'data pantry' will identify the types of vehicle energy storage systems available Each storage type will be coded as follows: "false" indicates that a specific type of storage is not present, while "true" signifies that the storage type is indeed present.
• Compressed natural gas (CNG/LNG)
All bits shall be set to zero to indicate an unknown or other type of energy storage
NOTE This information may be unreliable if there has been a change of vehicle propulsion type (e.g from gasoline to CNG)
NOTE More than one bit may be set if there is more than one type of energy storage present.
Time and timestamp (UTC sec)
The IVS will maintain a 'data pantry' that records the timestamp of the initial transmission of any specific data communication from regulated commercial freight vehicles to the relevant jurisdiction or its agent through a wireless network.
As seconds elapsed since midnight January 1st, 1970 UTC
Failure value for time stamp set to “0”
The date and time shall be stored with a resolution of 1 second.
Location
The IVS's 'data pantry' will maintain the vehicle's location, which will be consistently updated in the WGS84 format The update frequency is not specified in this section of ISO 15638 and may depend on product design or jurisdictional regulations.
It shall be at the responsibility of the IVS provider to determine how the location data is established
The confidence bit is only used for an eCall message
For error estimation in TARV see 8.3.12.
Latitude and longitude ±DD.DDDD±DDD.DDDD degrees ±DDMM.MMM±DDDMM.MMM degrees and minutes ±DDMMSS.SS±DDDMMSS.SS degrees, minutes and seconds
In cases of GNSS satellite signal interruption and subsequent reacquisition, the IVS GNSS receiver will begin collecting and storing vehicle position data promptly If the interruption lasts less than seven days, this process will start within 60 seconds of reacquiring the signals For interruptions of seven days or longer, the receiver will initiate data collection within five minutes of reacquisition.
The representation of altitude is optional The unit is the metre unless the foot is specified As:
8.3.11.2.1 Position latitude shall be as determined in WGS84
EXAMPLE 48°18'1.20" N = 48.3003333 lat= (48*3600)+(18*60)+1.20}’’ = 173881,200’’ which encodes to the following value:
If latitude is invalid or unknown, the value 0x7FFFFFFF shall be transmitted
The latitude position determined by the IVS GNSS receiver must remain within 13 meters of the country average for absolute horizontal position, based on 95% of observations This requirement is applicable when utilizing a minimum of four satellites and maintaining a 'Horizontal Dilution of Precision' of less than 4.
8.3.11.2.3 The resolution of the stored latitude position calculated by the IVS GNSS receiver shall be to 1 degree or better
8.3.11.2.4 The longitude position calculated by the IVS GNSS receiver shall not deviate by more than 13 metres
8.3.11.3.1 Position longitude shall be as determined in WGS84
EXAMPLE 11°37'2.52" E = 11.6173666 long= (11*3600)+(37*60)+2.52}’’ = 41822.520’’ which encodes to the following value:
When longitude is invalid or unknown, the value 0x7FFFFFFF is utilized This represents the absolute horizontal position country average for 95% of observations, achieved by using at least four satellites and maintaining a horizontal dilution of precision of less than 4.
8.3.11.3.2 The resolution of the stored longitude position calculated by the IVS GNSS receiver shall be to 1 degree or better
8.3.11.3.3 The longitude position calculated by the IVS GNSS receiver shall not deviate by more than 13 metres
Position altitude shall be as determined in WGS84
Units: Metre (unless foot is specified by the jurisdiction [4.9])
Where altitude data is not available, 0000 shall be provided
When providing or recording location data the IVS shall also record and present the number of satellites present during the calculation in the format:
Where N= the number of satellites present
8.3.11.6 Location/direction degree of trust
This confidence bit is only used for an eCall message
For error estimation in TARV see 8.3.12.
Error estimation (covariance matrix)
Error estimation of location is calculated within GNSS by a Kalman filter (described in ISO 15638-1)
By taking the sources available, both from the GNSS and other on-board equipment an error estimate, known as a ‘covariance matrix) can be established
ISO 15638 does not provide an interpretation of the values in the covariance matrix, as their significance can vary based on context Instead, this interpretation is expected to be determined by the relevant system of the application service provider.
This part of ISO 15638 determines the format of the covariance matrix data
The calculation of data is determined by system design, ensuring alignment with the mathematical principles of the Kalman filter As illustrated in Figure 10, the process for calculating the covariance matrix is depicted.
The Kalman filter is a sensor fusion algorithm that combines control inputs and measurements from sensors to provide a more accurate estimate of a system's varying state than any single measurement could offer.
A Kalman filter processes measurements of system inputs and outputs along with statistical parameters, including noise covariance matrices, to produce optimal estimates of state variables and the covariance matrix of estimation errors Its enduring popularity stems from the fact that, under a broad range of conditions, these estimates are proven to be optimal, representing the best possible outcomes based on the available information.
All measurements and calculations derived from models inherently involve some level of estimation Factors such as noisy sensor data, approximations in the governing equations, and unaccounted external influences contribute to the uncertainty in determining a system's state The Kalman filter effectively mitigates this uncertainty by combining predictions of a system's state with new measurements through a weighted average approach.
The weights in a Kalman filter are derived from covariance, which quantifies the uncertainty in predicting a system's state, and can be viewed as a form of linear quadratic estimation This process yields a new state estimate that is a weighted average, positioned between the predicted and measured states, resulting in improved uncertainty estimation Notably, the Kalman filter operates recursively, relying solely on the most recent "best guess" of the system's state rather than the complete historical data to compute the new state.
The state estimate and covariances are represented in matrices to manage the multiple dimensions in calculations, enabling the depiction of linear relationships among various state variables, including position, velocity, and acceleration, within transition models or covariances.
The data field will include a variable length data object to accommodate the covariance matrix of the kinematic state estimation error, which may also encompass other relevant parameters, all within a two-byte data structure The methods for obtaining and interpreting this data will depend on system design and are not standardized, allowing for optimal performance and continuous improvement as data sources evolve.
The covariance matrix data object must include a state vector ID to specify the number of states (N) and their definitions It should also contain N variance values, which are the square roots of the diagonal elements (D) of the covariance matrix (R) Additionally, the object must feature N(N-1)/2 non-zero values from the lower triangular matrix (L), where the relationship R = LDL holds true.
The total number of elements to be stored is given by the formula \$\frac{N(N+1)}{2}\$, while two bytes are adequate for at least \$\frac{N(N-1)}{2}\$ of these elements The encoding of the \$N\$ diagonal elements is influenced by the selected units for the state variables and the application of dynamic scaling.
All covariance matrices are positive semi-definite, allowing for the direct calculation of their square roots instead of the matrices themselves This approach reduces the number of octets needed to achieve a specified precision by a factor of two.
The final data shall be transmitted in 4 bytes, with any unused bits as padded zeros.
Direction of travel
The IVS shall determine direction of travel of the vehicle in WGS84 or GDA94
The IVS GNSS receiver must maintain a travel direction accuracy within 4 degrees of the actual path for 95% of observations, utilizing a minimum of four satellites and ensuring a horizontal dilution of precision of less than 4.
The resolution of direction of travel determined by the IVS GNSS receiver and recorded by the IVS shall be to
The IVS will maintain a 'data pantry' that records the vehicle's travel direction, which will be updated regularly This direction will be measured in 2° increments from magnetic north, ranging from 0° to 358° in a clockwise manner.
The frequency of update is not defined in this part of ISO 15638 and may be a feature of product design or regulation of the jurisdiction [4.9]
The obligation to present data as specified in this subClause is an operational necessity, while the method for determining the direction of travel is left to the discretion of the IVS provider.
The current vehicle heading value shall represent the vehicle’s real direction of travel; random fluctuations of
GNSS signals shall not affect the value sent
Manufacturers of IVS must ensure that the recent location parameters provided do not suffice for determining vehicle speed, except when the regulated application service specifically aims to monitor or report speed This requirement is not explicitly defined in this section of ISO 15638.
Ignition status
When providing or recording location data the IVS shall also record and present the status of the vehicle ignition (on / off / disconnected) as:
Other movement sensors
When providing or recording location data, the IVS shall also record and present the status of any other independent movement sensors present (movement/no movement/disconnected) as:
Where m=movement, n=no movement, d=disconnected.
IVS identification
The ISO 15638 suite of standards defines the IVS (in-vehicle system) functionality, which can be executed by either a single on-board unit (OBU) or a combination of equipment installed at various locations within the vehicle.
Nonetheless, whatever the configuration, it performs the functionality of the IVS as defined in the relevant ISO
15638 standards deliverable, or combination of ISO 15638 standards deliverables
To ensure unique and unambiguous identification of the IVS for certain TARV application services, an application within the facilities layer will generate an 'IVSID' file This file, stored in the data pantry of the IVS, will contain a distinct identification for the IVS.
The unique identification of the IVS differs from that of the vehicle itself, as the IVS may be replaced or updated throughout the vehicle's lifespan to meet new application service requirements Furthermore, when a prime mover and multiple trailers each possess their own IVS, a single vehicle can have multiple IVS assigned during a journey.
The IVS identification must be unique, clear, and permanent as long as the IVS functionality remains unchanged Any significant alteration to the IVS function, whether implemented in a single OBU or multiple devices—excluding memory expansion—will necessitate the creation of a new IVS with a distinct identity.
Registration procedures, including the structures mandated by national issuing authorities, are essential for compliance Detailed provisions for registration are outlined in Annex A (normative) of ISO 14816, which is also included as Annex A in ISO 15638.
The identity shall be consistent to ISO 14816 CS1 (Clause 4,7 of ISO 14816) and shall provide an unambiguous identification element of 56 bits (PER encoding) as:
8.3.16.1 ISO 14816 CS1 definition (IVS identification data concept)
CS1 ::= SEQUENCE { countryCode CountryCode, issuerIdentifier
Value assignment is done in accordance with ISO 3166 and by using
the ITA.2 alphabet For value assignment, please refer to
http://www.nni.nl/cen278/14816_NRAI_register_by_country.html
Refer to Annex A of the current version of ISO 14816 for registration
NOTE the version current at the time of publication of this part of ISO 15638 is reproduced as Annex A of this part of ISO 15638 for the convenience of the reader
Manufacturers can incorporate their unique identity for batch identification and service quality, using this option alongside the IVS unique identification specified in section 8.3.15.
Manufacturer identification of OBU’s used as all or part of the IVS shall be in accordance with ISO 14816 CS2 (Clause 4.8 of ISO 14816)
Manufacturers Numbering allows manufacturers to implement a country-independent numbering system, primarily serving as an electronic serial number for quality assurance and quality control (QA/QC) purposes Additionally, this numbering scheme can function as a cryptographic hidden identity in systems that demand both anonymity and robust security.
The structure defined in ISO 14816 details the content of the manufacturers numbering data ‘primitive’ and is to be read in conjunction with the notes shown below the structure
The registration procedures align closely with those of CS1, but unlike CS1, the structures are not registered with any National Issuing Authority For detailed registration provisions, refer to Annex A (normative) of ISO 14816.
The Numbering Scheme views the ID as a data element, and the common basic data structure is only a data
8.3.17.1 CS2 definition (manufacturer identification data concept)
CS2 ::= SEQUENCE { issuerIdentifier ManufacturerIdentifier, serviceNumber ServiceNumber
Driver(s) identification
The ‘data pantry ’of the IVS shall record the identification of each and every driver of the vehicle
Driver identification consists of two components: the mandatory jurisdiction identification, which requires the current driver's license number, and the optional user authorization, which can be determined by the jurisdiction or the user as needed.
Driver identification is crucial vehicle data, as it indicates who is operating the vehicle at any given moment This information may also be necessary for applications that are not directly related to driver monitoring services.
The IVS must be equipped to record the driver's identification each time the ignition is activated, as well as during driver changes throughout a journey, regardless of whether the ignition is turned off at the time of the switch This requirement is outlined in ISO 15638-3.
The method for capturing the driver's driving license is not detailed in ISO 15638, yet it should be considered a design parameter for both jurisdictions and equipment manufacturers It is important to note that the driver of a vehicle may change frequently.
In many cases a vehicle is sent on a journey with two drivers, who rotate in order to abide with driving hours regulations
Driving licence types and formats vary significantly worldwide, necessitating careful consideration by jurisdictions To enhance machine readability, jurisdictions lacking suitable formats may opt to issue regulated commercial freight vehicle drivers a barcode, RFID, or USB device Additionally, jurisdictions could explore facial recognition or iris recognition technologies to verify that the driver corresponds with the provided licence number Ultimately, these measures must be evaluated by each jurisdiction, with bilateral agreements established for cross-border travel.
Each time a new or replacement driver operates the vehicle, the driver's driving licence number must be provided This section of ISO 15638 does not specify the method for capturing this data.
The format of the driver identification is in two parts: a) Jurisdiction identification b) User authorisation
The jurisdiction [4.9] identification shall be the driver license identification shall be stored in the format:
Issue date Issuing jurisdiction [4.9] Driver name Vehicle classes Expiry date
Drivers are licensed to operate specific vehicle classes, which are presented in alphanumeric format as defined by the issuing authority These classes are organized in the order they appear on the driver's license, with each class separated by a comma.
Issue and expiry date to be listed in yymmdd format
User authorisation of the driver may or may not be required at the discretion of the jurisdiction [4.9] , or the user
If not required, 000000 shall be recorded
User authorization for drivers may be necessary for insurance purposes, as a driver licensed to operate a specific vehicle class may require additional experience and training to transport specialized loads, such as hazardous materials or oversized cargo.
Where required, the driver user authorisation shall be stored in the format:
Issue date Issuing organisation Driver name vehicle classes Expiry date
Vehicle classes will be presented in alphanumeric format, mirroring the structure found on driving licenses The authorized vehicle classes will be listed in the same sequence as they appear on the driving license, with each class separated by a comma.
The issuing organisation to be the company registration number or employer registration number that is unique within the jurisdiction [4.9], as determined by the jurisdiction
Issue and expiry date to be listed in yymmdd format
Trailer identification
The ‘data pantry’ of the IVS shall carry an identification of each of its trailers (if any) in a format In accordance with ISO 17262 CS9 (Clause 7.3).
Load data
The IVS's 'data pantry' will, when feasible, include a vehicle or trailer load profile formatted according to one of the options outlined in ISO 26683-2, which pertains to intelligent transport systems for freight land conveyance content identification and communication.
Organisation of the TARV LDT
LDT [4.10] data must be transferred in accordance with the security and communication guidelines outlined in ISO 15638-4 and ISO 15638-2 The standards address the data presentation aspects at the transfer point of the LDT [4.10] data concept, which are not detailed in this document.
Data will be transmitted using ASN.1 Packed Encoding Rules (PER) as specified in ISO 8824 (Parts 1-4) and ISO/IEC 8825-2 The presentation format outlined here is semantic, ensuring compliance with the required standards for data encoding.
TARV LDT [4.10] data shall be presented as in Table 1:
Concept name Concept format Concept semantic content Clause
DataFormatVersion AaaSs0 Country, Subpartition, Version 8.3.1 ;
PrimeServiceProviderIdentifier xxxx:xxxx:xxxx:xxxx:xxxx: xxxx:xxxx:xxxx
ApplicationServiceProviderAddress ITSaid1ext::=CHOICE{ content [0]
1), contained in two octets of ITSaid extension [1]
And shall use APIs issued by an international registration authority
SessionControlData As specified in ISO 15638.2 for specific media
VehicleUniqueIdentifier Registration number of the regulated commercial vehicle vehicle registration number as defined in ISO 14816 (Automatic Vehicle Identification – Numbering and data structure, Clause4.10 CS4 Vehicle license coding
CountryCode, alphabetIndicator AlphabetIndicator, licPlateNumberLicPlate Number
VehicleClassIdentifier 51 As specified in ISO 24534
See ISO 24534 for VIN variant provisions
World Manufacturer Index (WMI) Vehicle Type Descriptor (VDS) Vehicle Identification Sequence (VIS)
1st-3rd digit - World Manufacturer Indicator, ISO 3780 Who made the vehicle
4th-8th digit - Manufacturer Specific Model of vehicle, engine, bodystyle, etc
9th digit - Check digit Mathematical Formula to determine if VIN is real
10th digit – Year Model year of the vehicle
11th digit - Assembly Plant - Manufacturer Specific The assembly plant that built the car
12th - 17th digit - Sequence NumberUsually starts at 100001,200002,A0000A, B0000B, etc
Gasoline;Diesel;CNG;LPG;Elec tric;Hydrogen
Time&Timestamp 1297339499 UTC seconds since 1970/01/01 8.3.10 ;
No of satellites present, Trust (true/false)
Concept format Concept semantic content Clause
Ignition Ign 1/0/d On/off/disconnected 8.3.14 ;
Sensor number Mvt m/n/d Where m=movement, n=no movement, d=disconnected
ManufacturerIdentification INTEGER (0 65535) ISO 14816 Manufacturer identifier 8.3.17 ;
J=alphanumeric form as determined by the issuing jurisdiction Listed in sequence as shown on the driving license, with classes separated by a comma
U= Issue date Issuing organisation Driver name vehicle classes Expiry date
TrailerIdentification In accordance with ISO 17262
LoadData One of profile options specified in ISO 26683-2
The recipients of the TARV LDT [4.10] are application service [4.2] providers and jurisdictions [4.9]
The TARV LDT data content is inherently self-identifying for vehicle identification and instances, eliminating the need for specific titling Implementers have the flexibility to utilize their own internal conventions to differentiate between various instances of TARV LDTs for internal purposes.
To ensure security and privacy, the prime service provider or application provider of a TARV LDT must not share data with any third party, except for the contracted user or as outlined in the user’s contract.
To ensure security and privacy, any jurisdiction receiving a TARV LDT must not share this data with third parties, except with the user, unless required for legal action In such cases, access to the TARV LDT data will be governed by the relevant legislation under which the legal action is initiated.
9 Additional data provision options for ‘core application data’ and regulated applications
General
According to ISO 15638, a jurisdiction is responsible for determining the data required from a regulated commercial vehicle operating within its boundaries.
Basic vehicle data essential for TARV application systems and cooperative intelligent transport systems across all vehicle classes is outlined in Clause 8 This data, which is crucial for safety and other cooperative transport systems, must be supported by all Intelligent Vehicle Systems (IVS) for regulated commercial vehicles globally and is stored in the TARV LDT.
Jurisdictions may establish extra requirements for additional data, irrespective of the regulated application services, to facilitate or support their implementation of these services at any given time.
Specific application services, whether regulated or commercial, will utilize dedicated application-specific instruments as outlined in their respective specifications These services will leverage an app to access the TARV LDT, along with data generated by onboard applications related to regulated service provision This data will be securely stored in a data pantry with restricted access rights for the regulated application services Information can be delivered either through a 'push' from the onboard app or a 'pull' from the application service provider's app.
Basic vehicle data is located in the main branch of the LDT for all equipped TARVs, while core application data can be found in the data pantry of these vehicles within a specific jurisdiction This data is supplemented by a specially designed 'side-branch' of the LDT, which is managed by an app provided or approved by the relevant jurisdiction.
Certain additional data concepts are tailored to specific application services, while others, though not universally required, may be necessary for multiple services.
Certain data, distinct from 'basic vehicle' data, is essential for various jurisdictions and applications This data bridges the gap between universally provided 'basic vehicle' data and the specific core application data required by jurisdictions to effectively regulate TARVs.
To enhance interoperability and reuse of data concepts across multiple applications, it is essential to establish common definitions, even if these concepts are not mandatory for all applications This approach is particularly relevant when servicing application provisions or adhering to jurisdictional requirements.
Populating that side-branch and or individual data concepts in the data pantry shall be ordered and effected by the app provided or approved by the jurisdiction [4.9] requiring that:
The local jurisdiction will outline its data requirements through an 'App' that is typically downloaded when the vehicle enters the area, or it may be provided by the jurisdiction prior to the journey.
The jurisdiction shall be responsible to ensure that the ‘App’ is both achievable and up to date;
The ‘App’ shall draw the basic vehicle data [4.4] from the TARV LDT [4.10]; and
The ‘App’ shall obtain the additional data to be added to the core application data [4.5] from the data pantry thus providing the jurisdiction [4.9] with the information that it requires
Figure 9 (above) shows a hypothetical example of core application data [4.5]
The jurisdiction's app solely requires data input, while a separate on-board app from the application service provider handles data calculations independently In certain cases, the jurisdiction may also supply this calculation functionality.
The jurisdiction receives only the calculated result of the direction of travel from the application service provider, without access to the underlying raw data from recent vehicle locations Consequently, they cannot utilize this data for other purposes, such as calculating vehicle speed from various time and location combinations If speed data is needed, the jurisdiction must make a direct request for it.
The command 'GETCoreData' transmits data exclusively to a specified IPv6 address, ensuring that the information is not returned to the requester for security reasons.
The selection of candidates listed in section 9.2, alongside the fundamental vehicle data outlined in section 4.4, is at the discretion of the jurisdiction to create the essential application data specified in section 4.5.
The purpose of defining these additional data concepts is to provide international interoperability so that where
9.2 provides some candidates for such data concepts that are likely to occur/recur.