Intelligent transport systems — Framework for collaborative Telematics Applications for Regulated commercial freight Vehicles TARV — Part 3: Operating requirements, “Approval Authorit
Generic service requirements
ISO/TS 15638-1 outlines the framework and architecture for TARV, detailing the roles and relationships of various actors involved For a comprehensive understanding of the TARV framework, readers are encouraged to consult ISO/TS 15638-1 This document defines the responsibilities of each actor concerning the fitting, maintenance, and use of IVS and TID, as well as the availability of generic data and application services.
Security aspects are dealt with in ISO 15638-4 TARV System security requirements
Generic vehicle information and data aspects are specified in ISO 15638-5
Specific application service provision aspects are defined in ISO 15638-6 ‘TARV Regulated applications’, and ISO 15638-7 ‘TARV Other applications’
The roles and responsibilities of actors in TARV are outlined in ISO 15638-1, which details the framework and architecture This standard specifies the relevant clauses and subclauses that define the duties of these actors.
User
User specification US1: ‘Prime User’
The prime user [4.22] of the application service shall be the operator of the regulated commercial freight vehicle.
User specification US2: ‘Secondary User’
The driver shall be considered a secondary user [4.26] when fulfilling regulatory requirements for the provision of driver information and data to the regulator or his agent.
User specification US3: Mandatory application service enrolment
Users must enroll in mandatory applications for regulated commercial freight vehicles, as specified by jurisdictional regulations and provided by a service provider, with variations possible between different jurisdictions.
User specification US4: Voluntary application service enrolment
8.2.4.1 Voluntary commercial application service enrolment
Users can voluntarily enroll in a commercial application service for regulated freight vehicles through the IVS, provided by an application service provider, with variations depending on the jurisdiction.
8.2.4.2 Voluntary regulated application service enrolment
Users can voluntarily enroll in a regulated application service for commercial freight vehicles through the IVS, with availability varying by jurisdiction.
User specification US5: Service provider engagement
Upon enrolling an application, the user must engage a service provider to initiate operations under the application and pay any necessary fees as stipulated in the contract with the service provider.
Service provider
Service provider specification SP1 : Service provider definition
A regulated application [4.23] service provider [4.27] shall be an actor [4.1] that provides a regulated application service [4.24] for regulated commercial freight vehicles [4.25].
Service provider specification SP2: Service provider ‘Approval Authority’ requirement
A service provider offering a regulated application service for commercial freight vehicles must receive 'approved' certification from the jurisdiction's approval authority, ensuring they are qualified to deliver regulated Intelligent Transportation System (ITS) services to these vehicles.
Regimes for regulated application service provision
Application service providers may be offered or subcontracted by the jurisdiction, but they are more commonly supplied by third-party commercial enterprises that deliver Intelligent Transportation System (ITS) services.
In the initial years, service providers are anticipated to install the IVS in users' vehicles However, in the future, IVS platforms may either be optional or mandated equipment during manufacturing, depending on jurisdictional regulations Additionally, jurisdictions may permit the separation of equipment provision and maintenance from service provision.
In the open market, application service providers are commercial entities that deliver Intelligent Transportation System (ITS) services through wireless communication links with vehicles When a user opts for a single service provider for all regulated and additional commercial services, it is anticipated that these providers will also install and maintain in-vehicle systems (IVSs) in the user's vehicles, highlighting the critical roles of IVS installers and maintainers within the overall architecture.
In certain jurisdictions, users may face restrictions on their choices of service providers due to regulatory requirements aimed at maintaining control and ensuring quality of service These limitations can arise from liability concerns, resulting in users being limited to a single or a select few application service providers.
See ISO 15638-1 for further description of the regimes for application service providers [4.27].
Service provider specification SP3: Application service definition
Application services for regulated commercial freight vehicles must be clearly defined regarding the service provider's requirements and the necessary information and data to be provided to the jurisdiction and its agents, as well as to the users.
NOTE Some guidelines and specification or application services are provided in 15638-6 and 15638-7.
Service provider specification SP4: Service provision
The service provider will deliver the application service by wirelessly interacting with the vehicle to gather and process relevant data from the IVS This data will be used to generate jurisdiction reports as per the application service requirements set by the jurisdiction for regulated services Additionally, the provider will supply pertinent data to the user in line with their contractual agreement.
Collecting data from vehicles is essential for service delivery; however, the final results are analyzed and sorted by the service provider before being communicated to the relevant jurisdiction, as required by regulations, and to the user, as stipulated in the service contract.
Service provider specification SP5: Service provider charging
Service providers will charge users fees for the services rendered, as stipulated in the contract between the user and the service provider This arrangement is governed by the agreements established between the jurisdiction regulator and the service provider concerning the delivery of the regulated application service.
Service provider specification SP6: Service provider charging fees on behalf of
The service provider is responsible for collecting fees from the user as mandated by regulations set by the jurisdiction regulator This includes fees for permits, road usage, and potential violation penalties The provider will collect these fees from the user and ensure that the payments are forwarded to the appropriate jurisdiction.
The jurisdiction is responsible for determining the fees that service providers can set, which is influenced by the relevant legislation and regulations in place.
Service provider specification SP7: Service provider transmission of data to the
Service providers must transmit raw road usage data to the jurisdiction as mandated by local regulations, but they are prohibited from sharing any information that identifies specific vehicles, fleets, or drivers beyond what is required by those regulations.
Government authorities and researchers may need vehicle-specific data for various purposes, including research studies and safety oversight programs This data collection is permissible as long as there is a formal agreement between vehicle operators and the data-collecting entity.
Service providers [4.27] shall not be required to provide any information that breaches the privacy laws of the jurisdiction [4.18] See also 16
Service providers may provide anonymous aggregated data to the jurisdiction's transport departments upon request, potentially for a fee or as a licensing condition It is essential for both the jurisdiction and the service provider to carefully consider privacy aspects in these situations The jurisdiction is prohibited from sharing or using any information that violates its privacy regulations.
Service provider specification SP8: Provision of non-regulated commercial services
Service providers may offer additional commercial services to users through the same IVS, provided they have obtained approval from the jurisdiction's regulator or its designated authority This approval should not be unreasonably withheld Furthermore, it is essential that the introduction of any non-regulated services does not significantly impact the quality of the regulated services being provided.
Wireless communications service provider
Service provider specification SP9: Wireless communications service provision
Service provision may take place using different wireless media, which shall conform to ISO 15638-2.
Service provider specification SP10: Responsibility for wireless communications service
The service provider is primarily responsible for any contracts with third-party service providers involved in delivering regulated or commercial application services Additionally, the service provider must ensure that the communication service provider complies with regulatory requirements for the wireless provision of the application service.
When utilizing a general communications medium, such as GSM or UMTS, to deliver a regulated application service, the service provider must guarantee sufficient access to this medium This access is essential for the effective provision of the regulated service, in compliance with the jurisdiction's requirements.
IVS installer
Original equipment manufacturer specification OEM1: Responsibility where IVS is
When the IVS is integrated during vehicle manufacturing as part of the OEM specifications, the responsibility for installation falls on the vehicle manufacturer or their agent The manufacturer must ensure that the IVS equipment is type approved or meets regulatory performance standards, and that it is properly installed and operational at the time of sale.
Service provider specification SP11: Responsibility where IVS is installed post
In a market model where a user selects a single service provider, the provider is responsible for ensuring that the equipment is type approved and meets or exceeds applicable regulatory performance requirements, as well as ensuring correct installation.
In this environment, each service provider offers and installs their own type of IVS, allowing them the flexibility to implement various market models to recover the costs associated with the equipment and its installation, similar to the practices seen in mobile telecommunications and satellite television markets.
When users choose to utilize multiple service providers, the installation of IVS equipment is often handled by a third-party commercial enterprise It is essential for the jurisdiction to implement a quality control regime that guarantees the functionality of various systems and equipment This regime must be tailored to the specific regulations of the jurisdiction and should designate a single party responsible for the proper installation and operational integrity of the equipment.
In situations where the IVS is not included in the original equipment, it is anticipated that equipment installers will need to be registered and approved by the relevant authority in many jurisdictions, although this is not mandated by the Standard.
The jurisdiction establishes the requirements for the application service and is responsible for certifying, approving, and appointing service providers, ensuring their accountability in delivering the service Additionally, the jurisdiction may choose to approve IVS equipment providers or delegate this responsibility to the service provider, who will then be held accountable while having some discretion in managing their subcontractors.
IVS maintainer
User responsibility US6: Responsibility to maintain the IVS
The user shall select and engage a single service provider to manage the IVS, which will be designated as the 'prime service provider' and will assume all associated responsibilities.
‘prime service provider’ defined in this specification as part of its contract with the user for the duration of the contract.
Service provider specification SP12: Responsibility of the service provider contracted to
An application service provider responsible for maintaining an IVS must report the contract and accept maintenance responsibilities to the jurisdiction regulator, following the guidelines set by the jurisdiction.
8.6.2.2 In the event of malfunction
If an IVS or TID fails to operate as specified, the application service provider or maintainer must promptly communicate with the user to address the issue Additionally, they are required to report the malfunction, along with an estimated resolution time, to the jurisdiction regulator within a timeframe set by the jurisdiction's regulations The application service provider or maintainer must adhere to the specified timeframe established by the jurisdiction for these actions.
In accordance with regulation [4.18], it is essential to report to the jurisdiction regulator [4.19] Additionally, immediate and diligent efforts must be made to ensure that IVS data records stored in the IVS memory are either transferred to the prime service provider's system [4.21] or have already been successfully transferred.
The application service provider must report to the jurisdiction regulator within a specified timeframe any evidence of tampering or attempts to tamper with the IVS security seals, TIDs, or connections, as well as any malfunctions of the IVS or TID that seem to result from such tampering.
The application service provider/maintainer shall NOT advise a user [4.31] of any detection of tampering [4.28], or suspected tampering, with their IVS and/or TID(s)
If an approved IVS or TID experiences multiple malfunctions of the same type (excluding programmed maintenance issues), the application service provider or maintainer must inform the jurisdiction regulator about each malfunction, including its apparent cause and the corrective action taken.
NOTE Any remedy involving any change to the type approved [4.29] IVS or TID hardware or software shall require re-certification
For each IVS and TID, the prime service provider [4.21] or its installation and maintenance agents shall document all installation, operation, programmed maintenance and remediation-of-malfunction activity
1) IVS ID and, if applicable, TID ID
2) version numbers of the hardware and software
3) date and time of activity
5) details of the activity including cause of malfunction and the remediation
The prime service provider and its installation and maintenance agents are required to keep archives of the specified documentation for a duration mandated by the jurisdiction, which is recommended to be no less than four years.
Jurisdiction
Jurisdiction specification JS1: Definition of regulated application services for TARV
The jurisdiction [4.18] shall define and specify regulated application services [4.24] that are mandatory or voluntary for regulated commercial freight vehicles [4.25].
Jurisdiction specification JS2: Definition of status of regulated application services for
The jurisdiction [4.18] shall determine whether the provision of a defined regulated application service [4.24] for
TARV shall be mandatory or voluntary
8.7.3 Jurisdiction specification JS3: Obtain supporting legislation/regulation for a regulated application service for TARV
The jurisdiction [4.18] shall be responsible to obtain all legislation and regulations that are required to implement a regulated application service
8.7.4 Jurisdiction specification JS4: Manage and regulate the provision of the regulated application services
Without this part of ISO 15638 prescribing the domestic arrangements within any jurisdiction, the jurisdiction
The entity shall oversee and regulate the delivery of the chosen regulated application services, which includes selecting applicable standards, facilitating adjudication and mediation, and managing certification and auditing processes.
The jurisdiction can achieve this either directly through its functions or by appointing a regulator, who may or may not serve as the approval authority, depending on the jurisdiction's choice.
ISO 15638-1 emphasizes the necessity for third-party service providers to ensure compliance with jurisdictional requirements when delivering services to users To guarantee proper service provision, both the jurisdiction and users must have confidence in the service's adherence to regulations Consequently, service providers must obtain approval from the relevant regulatory authority, which is a critical element of the system's architecture This approval authority may delegate the auditing of services to appointed auditors to verify compliance with established standards.
An 'Approval Authority' is an entity responsible for certifying 'Service Providers' and ensuring the maintenance of service quality This authority may be an independent organization chosen by the relevant jurisdiction, the jurisdiction itself, or established through other specified arrangements.
Certification procedures that formally confirm an applicant has met all requirements for service provider appointment are not specified in ISO 15638 Instead, these procedures fall under the responsibility of the approval authority and its jurisdiction.
Certification procedures for application services vary by jurisdiction and are not covered by ISO 15638 However, it is advisable for approval authorities to refer to ISO 17000 and ISO Guide 65 when creating and executing these procedures.
Jurisdiction specification JS5: create or appoint a ‘Approval Authority’
Without this part of ISO 15638 prescribing the domestic arrangements within any jurisdiction, the jurisdiction
[4.18] shall be responsible for determining the role and responsibilities of any approval authority [4.4] it creates or appoints to approve service providers [4.27] and IVS
An approval authority is an entity that certifies service providers and ensures the maintenance of service quality This authority can be a single independent organization chosen by the responsible jurisdiction, the jurisdiction itself, or other arrangements as defined by the jurisdiction.
Approval authority pertains to the validation of specific attributes related to an object, individual, or organization In this context, it encompasses the approval of service providers as well.
Requirements for IVS and any TIDs must be clearly defined as tests that need to be passed Each requirement results in a verdict of either passed or failed, which serves as the basis for the approval authority's decision.
8.8.2 ‘Approval Authority’ specification AA1: Consider and appoint candidates to be service providers
On behalf of the jurisdiction, and to its regime, the ‘Approval Authority’ shall consider candidates to be service providers [4.27] and shall appoint candidates to be service providers
8.8.3 ‘Approval Authority’ specification AA2: Test and approve service providers
The approval authority is responsible for assessing and approving appointed service providers to ensure they meet the necessary requirements for delivering application services This includes evaluating their business models for user charges and determining the duration of their approval, along with renewal options and requirements.
8.8.4 ‘Approval Authority’ specification AA3: Audit service providers
Approval authority ensures that a service provider meets certification requirements at a specific time However, ongoing audits are necessary to confirm that the service provider consistently maintains the minimum service level as per the certificate of approval.
On behalf of the jurisdiction, and to its regime, the approval authority [4.4] shall audit [4.5] the performance of service providers [4.27] from time to a regime determined by the jurisdiction [4.18]
The audit requirements encompass operational, technical, and financial capabilities specific to regulated applications The primary objectives of the audit function include supporting policy objectives related to legislation, monitoring compliance by service providers with standards and approval agreements, ensuring the reliability and accuracy of information provided by service providers, assessing the integrity of that information, and enhancing the transparency and credibility of regulated applications.
8.8.5 ‘Approval Authority’ specification AA4: Type approve IVS
The approval authority is responsible for 'type approving' the IVS intended for installation after the vehicle's manufacture Additionally, OEM equipment installed during the manufacturing process must be certified as part of the vehicle's type approval certification.
8.8.6 ‘Approval Authority’ specification AA5: Test IVS functionality
The approval authority [4.4] is responsible for establishing a regime that tests and ensures the proper installation and capability of IVS equipment to deliver application services effectively.
Most jurisdictions and certification authorities are likely to fulfill this requirement through the use of an independent test house, although the chosen method ultimately depends on the specific jurisdiction.
Contract options
User requirement US6 : ‘Service Provider - User Contract’’
After installation, whether as original equipment or aftermarket, operators of regulated commercial vehicles must sign a contract with one or more service providers to access the chosen application services, regardless of whether the use is voluntary or mandated by law.
The contract will be established between a user and a service provider, specifically for a regulated commercial vehicle or a designated group of vehicles While the details of the contract and the services provided are not covered in this section of ISO 15638, it is essential that all contracts comply with the regulations set forth by the relevant jurisdiction.
The contract's duration and cancellation terms are not covered within this agreement Users must understand that if a regulated application service is mandated by the jurisdiction, it becomes a requirement rather than an option Upon termination of such a contract, users are obligated to secure a replacement contract Jurisdictions are encouraged, though not mandated by ISO 15638, to impose significant penalties on users who operate registered commercial freight vehicles without a contract for the required application services.
In environments with multiple service providers, users should retain the freedom to change their service provider, except when mandated by jurisdictional requirements This flexibility should be maintained within reasonable contract conditions.
According to ISO 15638, the initial service provider must act as the prime service provider and is responsible for maintaining the IVS under their contract with the user If the contract is terminated for any reason, the user has the option to select a new service provider to take on the role of prime service provider.
To establish itself as the primary service provider, the appointed service provider must inform the relevant jurisdiction of its designation in accordance with the jurisdiction's guidelines This notification should occur both at the time of installation and commissioning, as well as subsequently, for the designated IVS/regulated commercial freight vehicle combination.
When a user sells or transfers a regulated commercial freight vehicle, the vehicle's identity and IVS must remain unchanged The jurisdiction is responsible for facilitating this transfer, potentially through the vehicle registration process Additionally, any new service provider contracted to offer application services for the vehicle must inform the jurisdiction or its regulatory authority about the change of user.
The service provider, or one of the service providers in a multiple environment, shall contract with the user to
Physical
IVS functional description
The IVS, or In-Vehicle System, is essential equipment installed in vehicles to deliver specific telematics functions This system can consist of a single physical on-board unit or integrate telematics capabilities across one or multiple devices within the vehicle.
An OEM, typically the vehicle manufacturer, can install the IVS, which often includes multiple functions Some of these functions are executed within the IVS, while others are carried out externally, with data likely transmitted to the IVS via the vehicle's CAN bus or J1939 bus network.
The prime service provider or their agent can install the IVS, which significantly reduces the chances of obtaining information from other vehicle sources This installation is more likely to result in an OBU that has most, if not all, of the necessary functionality developed within the IVS/OBU.
HMI aspects
The IVS must deliver clear visual and audible signals about the system's status and wireless connectivity, as well as indicate when a transaction is underway The specific nature of these notifications is not defined, allowing for marketplace design or jurisdictional specifications.
Data
IVS essential data collection
The IVS is required to collect and store essential data, including IVS identification, vehicle identification, vehicle class identification, and propulsion storage type Additionally, it must gather GNSS data, date and time data, vehicle position, direction of travel, and speed data If applicable, the system should also record trailer identification, alarm status, movement sensor status, ignition status, driver identification, load data, and self-declaration data.
The means by which this is achieved is defined in ISO 15638-5 (TARV generic vehicle information).
IVS essential data processing
The IVS shall be capable to calculate and store: a) position records b) speed records c) alarm records
For the eventuality that these are required in performance of an application service, but shall not actually make these calculations unless required to do so by an application service
The means by which this is achieved shall be as defined in ISO 15638-1, Clause 12 (Interoperability and the
TARV-ROAM ‘facilities’ layer, and the data detail shall be as defined in ISO 15638-5 (TARV generic vehicle information).
IVS identification
Each Intelligent Vehicle System (IVS) and its associated On-Board Unit (OBU) must possess a distinct identifier known as the IVS ID, as outlined in ISO 15638-5 (TARV – Generic vehicle information) This unique identifier is essential for the clear and precise identification of each specific IVS.
The IVS ID shall be visibly etched or marked on the outside casing of the unit in a manner such that it cannot be modified or removed
The IVS ID shall be stored in the non-volatile programmable read-only memory of the IVS (See 9.6 below)
The IVS ID shall not be able to be set or altered by any person other than the prime service provider
IVS specification IVS1: Robustness and suitability
Robustness
The IVS, in whatever form, units and connections, that it is instantiated, shall ensure that its mechanical, electrical and electronic strength matches the actual stresses of the operating environment
The design of an IVS must consider several critical factors, including communication, electronic, and mechanical capabilities, as well as durability and responsiveness It is essential to account for environmental impacts such as vibration, bumps, falls, and shocks Additionally, concepts from linear algebra, such as eigenfrequencies, eigenvalues, eigenvectors, and eigenspaces, play a significant role in the design process Material data and various design methods are also crucial components that contribute to the overall effectiveness of the IVS.
Designers of systems must address the evolving threats in the electronic environment and possess the technical skills to rectify faults It is crucial to ensure that the mechanical, electrical, and electronic strengths of the system align with the actual stresses of the operating environment and potential challenges ISO 15638-4 outlines specifications for security in TARV application services Additionally, the On-Board Units (OBUs) of an Intelligent Vehicle System (IVS) should be securely connected to the prime mover or rigid truck.
In respect of robustness aspects of software see 9.27.1,11.7, 12.10.5, 14.4.4, 14.4.19, and 14.6.2.
Suitability for use
9.3.2.1 The IVS manufacturer or installer shall provide to the jurisdiction regulator [4.19], evidence of compliance from an appropriate body, with the following, or equivalent(s) as approved by jurisdiction regulator: a) IVS complies with all of the performance requirements in this specification when subjected to the vibration to a reference specified by the jurisdiction [4.18] b) IVS complies with all of the performance requirements in this specification when subjected to the impact to a reference specified by the jurisdiction [4.18]. c) IVS complies with all of the performance requirements in this specification when subjected to the temperature and humidity specified to a reference specified by the jurisdiction [4.18]. d) IVS complies with the electromagnetic compatibility conditions specified in a reference specified by the jurisdiction [4.18] e) IVS components exposed to the elements comply with the dust and water ingress protection requirements of IEC 60529 Ed 2.1:2001; Table 7, Item 6 and Clause 13.4 and Table 8, Item 6 and Clause 14.2.6 f) IVS components mounted in the cabin shall comply with the dust and water ingress protection requirements of IEC 60529 Ed 2.1:2001; Table 7 Item 5 Clause 13.4 and Table 8, Item 4 and Clause 14.2.4 g) IVS and TID shall be tolerant to radio frequency and electrical interference as defined in 2004/104/EC, sections 6.7 and 6.8 with functional status ‘A’, Table 1 h) electromagnetic emissions from the IVS and TID shall not exceed the limits in 2004/104/EC, sections 6.9 using the pulse amplitude levels for either 12 or 24 volt systems as appropriate, Table 2 i) electromagnetic emissions from the IVS and TID shall not exceed the limits in CISPR 22:2004 (CIS participants report 22:2003), Class B, Table 6 j) Security seals of the IVS shall remain intact when exposed to the vibration and impact as specified above.
IVS specification IVS2: Availability
The IVS shall always be available if the ignition of the vehicle is switched on
In the event that the IVS is unavailable, the driver will be issued a warning The specifics of this warning are not defined and are left to the marketplace or jurisdiction to determine how it will be implemented.
IVS specification IVS3: Environmental
The IVS shall meet the legislation and regulations of the jurisdiction [4.18] in respect of environmental aspects of electronic equipment.
IVS specification IVS4: Secure data storage
The IVS manufacturer and installer must guarantee that the non-volatile data storage equipment is capable of withstanding a Delta-V crash, as defined by SAE J1455, lasting 50 ms.
The IVS manufacturer and installer shall ensure that the non-volatile data storage is tamper [4.28] resistant
The IVS manufacturer and installer must guarantee that data stored in non-volatile memory and RAM is exclusively accessible to the application service provider, preventing access from within the vehicle except by the IVS installer and maintainer.
Data storage security must comply with ISO 15638-4 (TARV – System security requirements), ensuring that collected or stored data and software memory within the IVS are inaccessible and unmodifiable by unauthorized individuals, devices, or systems The security and confidentiality of data in the IVS must be upheld at all times.
The means by which these measures are achieved are not defined within this part of ISO 15638 but are left to the marketplace or regulation of the jurisdiction [4.18].
Law enforcement and regulatory agencies can access necessary information from the application service provider, as per local regulations, rather than directly from the vehicle This process ensures that the security of the data stored on the vehicle remains intact.
IVS specification IVS5: Data storage means
The IVS must include a non-volatile data storage solution, such as a hard disk or flash memory, capable of retaining information without power It should have a minimum memory capacity of 100 Gigabytes.
If the amount of data collected before transferring to the application service provider exceeds the IVU's storage capacity, the new data will not overwrite the existing stored data.
NOTE This is for evidentiary reasons It prohibits the overwriting of data already collected, albeit at the expense of collecting new data.
IVS specification IVS6: Data input means
Drivers must input their driving license number each time they operate a vehicle The interface for this input will be determined by local regulations and may include options such as an IC card reader, RFID reader, USB2, barcode reader, or fingerprint reader, depending on the physical format of the driver's license.
The non-volatile data storage and RAM shall not be available from within the vehicle except to the IVS installer [4.16] and the IVS maintainer [4.17].
IVS specification IVS7: Central processing unit
The IVS must demonstrate its capability to execute the necessary operational programs to meet regulated service requirements The central processing unit should include a minimum of:
a processor with a minimum processing capability of 1 GigaHertz or higher
volatile memory (RAM/DRAM/SRAM etc.) of at least 100 Gigabytes
means to interact with process ISO 11519* and ISO 11898** CAN bus data
ISO 11519-1 Road vehicles Low-speed serial data communication Part 1: General and definitions
ISO 11519-2 Road vehicles Low-speed serial data communication Part 2: Low-speed controller area network (CAN)
ISO 11519-3 Road vehicles Low-speed serial data communication Part 3: Vehicle area network
ISO 11898-1 Road vehicles Controller area network (CAN) Part 1: Data link layer and physical signalling
ISO 11898-2 Road vehicles Controller area network (CAN) Part 2: High-speed medium access unit
ISO 11898-3 Road vehicles Controller area network (CAN) Part 3: Low-speed, fault-tolerant, medium-dependent interface
ISO 11898-4 Road vehicles Controller area network (CAN) Part 4: Time-triggered communication
ISO 11898-5 Road vehicles Controller area network (CAN) Part 5: High-speed medium access unit with low-power mode
Providers of in-vehicle platforms that offer various functions alongside regulated services are encouraged to utilize high-performance processors However, this recommendation should not be mandatory for service provision.
The testing of the central processing unit performance shall be completely independent of any envisaged application service.
IVS specification IVS8: Secure data processing
Secure data processing shall be achieved by compliance to ISO 15638-4.
IVS specification IVS9: Connectivity means to/from auxiliary equipment
The IVS shall have a means to receive inputs from and communicate with auxiliary equipment
The IVS shall have multiple means to connect with auxiliary equipment using standard physical interfaces
(USB2, USB3,USB Micro A and B, USB mini A and B, RS232, RS422 etc.) and the CAN bus [4.9] (PCAN TJA1054 or PCAN-BD10011S)
The IVS shall have an internal clock that operates independently of the supporting external power supply
In the event the external power supply fails or shuts down, the IVS internal clock shall operate for a period of at least 28 days
The IVS internal clock must maintain an accuracy that ensures it does not deviate by more than 1 second from UTC date and time over any 28-day period when utilizing GNSS signals.
The IVS internal clock must maintain an accuracy that ensures it does not deviate by more than 20 seconds per day from Coordinated Universal Time (UTC) over any 28-day period when GNSS signals are not utilized.
IVS specification IVS11: Communications means
The IVS shall have a means to receive inputs from and communicate with its communications capability (in order to receive and process instructions from the service provider)
The nature of that communication shall comply to one of the options defined in ISO 15638-2, which shall determine the nature and specification of the equipment required.
IVS Classification
IVS specification IVS12: CLASS A - able to communicate with its attached trailers
A CLASS A IVS is defined as an Intelligent Vehicle System capable of identifying attached trailers, particularly in cases of multiple hard-wired connections, and fulfilling all trailer identification requirements specified in section 9.
Class A IVSs must not only monitor a prime mover or rigid truck but also communicate with trailer identification devices on connected trailers This capability allows for the identification and recording of trailer identification information, and potentially content information, from each trailer identification device on up to 10 attached trailers.
The term 'Attached' refers to the connection of trailers to a prime mover or rigid truck, ensuring that the trailers move in unison with the vehicle This arrangement must comply with all relevant laws, regulations, and standards.
IVS specification IVS13: CLASS B – not able to communicate with its attached trailers
A CLASS B IVS is defined as an IVS that cannot identify attached trailers or fails to meet all trailer identification requirements outlined in section 9.
IVS specification IVS14: IVS identification of attached trailers
A CLASS A IVS must identify and document the trailer identification for all attached trailers within a vehicle combination, accommodating up to ten trailers This identification can be achieved through various methods, including both wired and wireless connections.
Identification can be initiated in various ways depending on the jurisdiction: it may be automatically triggered by an application service, activated when the vehicle ignition is turned on, or manually initiated by the driver, along with any other method specified by the jurisdiction.
IVS specification IVS15: Physical trailer marking
The trailer ID shall be visibly etched or marked on the outside casing of the trailer in a manner prescribed by the jurisdiction [4.18].
IVS specification IVS16: Equipped trailer identification (trailer ID)
The decision to equip a trailer with a trailer identification device is determined by the jurisdiction or to fulfill the requirements of a regulated or commercial application service.
IVS specification IVS17: Freight land conveyance content identification and
The equipped trailer ID must adhere to a unique identification scheme as outlined in ISO 26683-2 or ISO 17262, or follow a jurisdiction-specific identification scheme It is the responsibility of the jurisdiction to ensure that the identification scheme is both unique and unambiguous.
Equipped trailer identification devices
IVS specification IVS18: Equipped trailer identification devices
Equipped trailers shall each be equipped with a ‘trailer identification device’ (TID) in order to enable automatic identification and recording of fitted trailers by the IVS
The TID serves as a unique identifier for the trailer, its configuration including the number of axles, and data related to its connection with the prime mover or rigid truck Additionally, it may offer identification and status information regarding the cargo carried on the trailer.
The trailer identification device must be securely attached to each trailer monitored by the application service provider It should encompass all necessary hardware, software, and communication methods, whether wired or wireless, up to the point just before the IVS.
The trailer identification device must exclusively interact with the prime mover IVS when the trailer is physically linked to the prime mover or another connected trailer While the method of achieving this connection is not standardized, ensuring this communication is a mandatory requirement.
IVS specification IVS19: Trailer identification device requirements
The trailer identification device shall comprise: a) Central processor b) RAM c) include non-volatile programmable read-only memory
The trailer identification device (TID) include shall include non-volatile programmable read-only memory of a minimum of 1 gigabyte
The trailer ID shall be recorded permanently into the non-volatile programmable read-only memory of the TID
It shall not be possible to alter the Trailer ID in the non-volatile programmable memory without making the TID permanently inoperable.
IVS specification IVS20: Integrity of trailer identification
The transmission of trailer identification data from the TID to the IVS must include a method for authenticating Trailer ID data, such as a message authentication code that is exclusive to the application service provider This process requires jurisdictional approval and is essential for verifying the origin and integrity of the trailer.
The application service provider [4.27] shall document, to the satisfaction of the jurisdiction regulator [4.19], the trailer ID data authentication mechanism
See also ISO 15638-4 (TARV - System security requirements)
IVS specification IVS21: Power supply
An IVS installed in a prime mover typically derives its power from the vehicle's main power supply, but alternative arrangements can be implemented to ensure a dependable power source Additionally, an uninterruptible backup power supply is essential to maintain functionality during disconnections, such as in accidents or when the vehicle's power is intentionally disabled during servicing or storage.
The IVS shall be supplied with a reliable power supply that shall function whenever the vehicle ignition is switched on
The IVS must be equipped with a dedicated and secure independent power supply to ensure it remains operational for up to 7 days in case the vehicle's power supply is disconnected.
The IVS must be equipped with a dedicated and secure independent power supply to ensure it remains fully operational for one hour in case the vehicle's power supply is disconnected.
This Clause specifies the power supply requirements necessary for the IVS to operate effectively, excluding any other equipment linked to the IVS Additionally, the back-up power supply for the IVS must be configured to prevent depletion by other connected devices, ensuring compliance with the stipulated requirements.
When installing separate or additional IVS on trailers, it is essential to ensure an adequate power supply and recharging capability for the system While the specific methods for achieving this are not detailed, it is recommended that the same features apply to trailer-installed IVS If this is not feasible, the device must include a low power warning that can be automatically communicated to the service provider, along with a mechanism to alert the driver, although the method for this notification is not specified.
IVS specification IVS 22: external power supply failure/shut down
In the event of an external power supply failure, the IVS must retain stored data for a minimum of 28 days, monitor ignition and independent movement sensors for at least 7 days, and remain fully operational for at least 1 hour.
Continuing to monitor after the external power supply failure is essential for detecting any disconnection of the IVS and the independent movement of the prime mover or rigid truck, regardless of the GNSS signal.
IVS specification IVS23: Security seals
All On-Board Units (OBUs) of an Intelligent Vehicle System (IVS) or Tolling and Information Device (TID) must be secured with seals to detect any unauthorized removal or tampering, in compliance with jurisdictional regulations.
Removal or opening of an OBU shall be possible only by breaking the security seal(s) and the security seal(s) shall be such that if broken they cannot be reinstated
The OBU shall be placed in a position that facilitates inspection of the integrity of the security seal(s)
The security seal(s) shall clearly display signs of any unauthorised access, either visually and/or physically.
IVS specification IVS24: GNSS capability
The IVS shall have or shall have access to global navigation satellite positioning system (GNSS) receiver capability which shall consist of a GNSS receiver connected to a GNSS antenna
The IVS GNSS receiver and GNSS antenna shall comply with the radio communications regulations of the jurisdiction [4.18] and shall meet performance specifications defined by the jurisdiction
The IVS GNSS antenna shall be mounted in a position that meets the manufacturer’s specification for the vehicle combination and such that it optimises signal strength from the GNSS satellites
The quality of GNSS data is determined by the number of satellites utilized and the horizontal dilution of precision (HDOP) For effective quality assessment, the HDOP from the IVS GNSS receiver must be measured and recorded with a resolution of one degree or finer.
NOTE ‘used’ means the number of satellites whose signal is received and taken into account by the IVS in the determination of data.
IVS specification IVS25: Accelerometer capability
Section 9.27.2 outlines the necessity for multiple independent features to indicate vehicle movement, with accelerometers being a common solution Many regulated commercial freight vehicles may already have accelerometers integrated, or they can be added to an In-Vehicle System (IVS) These devices measure acceleration, and a 3-axis accelerometer can determine the orientation of a stationary platform.
Accelerometers are now affordable and widely utilized across various applications, particularly in modern vehicles They play a crucial role in airbag deployment systems by detecting rapid negative acceleration to assess collision occurrence and severity Additionally, accelerometers are integral to electronic stability control systems, where they measure cornering forces to enhance vehicle safety.
A 3-axis accelerometer measures the orientation of a stationary platform relative to the Earth's surface, but its accuracy diminishes when the platform is in motion For instance, during free-fall, the accelerometer will register zero acceleration, and when accelerating in a specific direction, it cannot differentiate between the acceleration due to gravity and the platform's movement In an aircraft making a coordinated turn with a 60-degree bank angle, the accelerometer will indicate a vertical acceleration of 2 G, even though the aircraft is tilted at that angle relative to the horizon.
This part of ISO 15638 does not determine any application or interpretation of accelerometer data, solely the architecture of the data and message
An accelerometer is not mandatory, but where accelerometer data is provided the data shall be stored in accordance with ISO 15638-5 (9.2.1).
IVS specification IVS26: Gyroscope capability
A gyroscope measures the rate of rotation around a specific axis and is commonly utilized to assess a vehicle's attitude, particularly in stability control systems However, relying solely on gyroscopes can lead to inaccurate information.
EXAMPLE a roll gyro in an aircraft in a coordinated turn with a 60 degree bank will be measure a rate of zero, the same as an aircraft flying straight and level
Gyroscope data also drifts with time, so additional error will accumulate over a period of minutes or even seconds
Therefore a combination of accelerometer and gyroscope are often used for applications
This part of ISO 15638 does not determine any application or interpretation of a combination of gyroscope and accelerometer data, solely the architecture of the data and messages
A gyroscope is not mandatory but where gyroscope data is provided the data shall be stored in accordance with ISO 15638-5 (9.2.2).
IVS specification IVS27: Still camera data
Where still images are recorded they shall be recorded as determined in ISO 15638-5 (9.2.3.1, JPEG/.jpg).
IVS specification IVS28: Video data
Where video images are recorded they shall be recorded as determined in ISO 15638-5 (9.2.3.2, MPEG/.mpg).
Alarm status data and records
IVS specification IVS29: Alarm types and data
The IVS is designed to generate and store alarm records in its non-volatile data storage for various critical events These include the reconnection of the external power supply, detection of movement via ignition while the external power is disconnected, and movement detection by an independent sensor under the same conditions Additionally, the system logs events related to the disconnection and reconnection of the ignition and the independent movement sensor, regardless of the power supply status It also monitors for unauthorized access to both data and software within the IVS, as well as the disconnection and reconnection of the GNSS antenna.
The data shall be stored in the format defined in ISO 15638-5.
IVS specification IVS30: Independent movement sensing
The independent movement features connected to the IVS are monitored to detect any tampering attempts, including disconnection or removal of the IVS These features aim to enable the detection of vehicle movement without relying on GNSS satellite signals One key feature for indicating vehicle movement is the ignition status, while additional movement detection may involve sensors, pending approval from the jurisdiction regulator.
4) some other such independent movement sensor such as an accelerometer or gyroscope or combination of the two
The IVS manufacturer shall document its chosen method of independent movement detection and connection
The connection of the independent movement features to the IVS shall be monitored and reported upon in accordance with 9.27.1 e through 9.27.1 h.
IVS specification IVS31: Vehicle location
The IVS shall be capable of calculation, storing and presenting the vehicle location with data defined in accordance with ISO 15638-5 (Claus 8.10 Location)
When providing or recording location data the IVS shall also record and present the number of satellites present during the calculation as specified in ISO 15638-5
When providing or recording location data the IVS shall also record and present the status of the vehicle ignition (on / off / disconnected) as specified in ISO 15638-5
The IVS must record and display the status of all independent movement sensors, indicating whether they are in motion, at rest, or disconnected, in accordance with ISO standards when providing or logging location data.
10 PROCEDURES FOLLOWING POWER-UP OF THE VEHICLE
IVS specification IVS32: When vehicle is powered up (ignition status ON)
Application service provider generates request for ‘Core Application Data’
10.2.1.1 ISO 15638-1 provides specification of basic vehicle data [4.8] and core application data [4.13] The basic vehicle data [4.8] concept is created and maintained in all circumstances regardless of jurisdiction [4.18] The core application data [4.13] concept is basic vehicle data [4.8] plus additional data elements required by the jurisdiction [4.18] (see also 12)
10.2.1.2 An application service provider [4.27] with whom the user [4.31] has enrolled may trigger a request to the IVS to send the core application data [4.13] at any time as defined in ISO 15638-5 (TARV Generic vehicle information)
In the CALM environment such requests may be targeted to a specific vehicle, or may be broadcast to all vehicles within the range of the communication network station.
IVS generates send of ‘Core Application Data’ (CAD)
The IVS can transmit core application data to the application service provider at any time, following the directives of the on-board application service program as outlined in ISO 15638-5.
Data compression
The data shall be sent using ASN.1 packed encoding rules (ISO 8824/ISO 8825).
Data acknowledgement
On successful receipt of the data requested by a command application service provider [4.27] shall send an acknowledgement ‘ DATA - ACK’ which shall take the form of one byte of ones (12012011).
In the event of failure to receive the ‘DATA-ACK’
If the IVS does not receive the 'DATA - ACK' within 30 seconds, it will update the basic vehicle data field as specified in ISO 15638-5 and resend the requested data, prefixed by a byte of zeros (0000000) This process will repeat until the 'DATA - ACK' is received.
IVS specification IVS34: Communication session clear-down
The application service provider [4.27] may clear-down an in-progress communication session at any time
The IVS shall not clear down any in-progress communication session that was instigated by the application service provider [4.27].
So long as the requirements provisions of the application service permit, the IVS may clear-down an in- progress communication session that it instigated at any time
The session clear-down procedures shall be as determined in ISO 15638-2 and the relevant CALM Media standard(s).
CAD not received correctly
If the CAD data is not received accurately, the application service provider will not send the 'DATA - ACK', prompting the IVS to resend the core application data.
11 RECORDS TRANSFER AND BACKUP PROCEDURES
Periodicity determined by the jurisdiction
The frequency at which IVS records are transferred to the system of the prime service provider [4.21] (‘Interval I’) shall be determined by the jurisdiction [4.18].
Frequency of records transfer
11.2.1 The transfer of stored data from the IVS to the application service provider [4.27] shall be performed at
‘interval I’ provided that the IVS is in the communication coverage area offered by the application service provider [4.27] and the vehicle is in operation
If a vehicle is out of communication coverage or not operational during the scheduled data transfer, the transfer will begin within 5 minutes once the communication network is restored and the vehicle is operational.
Records to be transferred
The IVS is required to transmit all records generated since the previous data transfer, referred to as 'stored data' in ISO 15638 This stored data must begin with the IVS identification and a timestamp, both defined in ISO 15638-5, and conclude with the IVS identification as specified in the same standard.
IVS unambiguous identity timestamp data
Procedures for transfer of ‘stored data’
IVS specification IVS35: ‘stored data’ Communication set-up
Upon reaching 'interval I', the 'stored data' concept will be filled with all records generated since the previous transfer to the prime service provider This data may also be compiled in a file since the last transfer and will be updated accordingly, including the identity and timestamp as outlined in section 11.3.
The means by which the in-vehicle equipment provider populates and updates the ‘stored data’ concept is a matter for product design and outside the scope of this Standard.
IVS generates send of ‘stored data’
If the communication channel with the application service provider is already established, the IVS sends the 'stored data' field Otherwise, the IVS must first establish the communication link by calling the IPv6 address of the application service provider, which is stored in the IVS.
The CALM media standard and its communication protocols are outlined in ISO 15638-2 Once the communication channel is established, the 'stored data' field should be transmitted, prefaced by one byte of alternating zeros.
NOTE The stored data field contains all of the information for the application serviceprovider [4.27] to be able to interpret it uniquely.
Data compression
The data shall be sent using ASN.1 packed encoding rules (ISO 8824/ISO 8825).
Stored data acknowledgement
Upon successfully receiving the stored data, the application service provider will issue an acknowledgment, referred to as 'SD - ACK' This acknowledgment will consist of a single byte, alternating between zeros and ones, beginning with '1'.
In the event of failure to receive the ‘SD-ACK’
If the IVS does not receive the 'SD - ACK' within 30 seconds after sending data, it will update the stored data field and resend it, starting with a byte of alternating zeros and ones (01010101) This process will repeat until the 'SD - ACK' is received.
Deletion of data stored in the non-volatile memory of the IVS
IVS data records deleted only after fulfilment of conditions
IVS data records stored in the IVS shall only be deleted after fulfilment of the following conditions:
The data has been successfully transferred and acknowledged as received by the application service provider and either
The data is more than one year old or
The memory designated in the data specifications of ISO 15638 or ISO 15638-5 has been utilized, leading to the overwriting of the data field as outlined in this section or in ISO 15638-5.
To meet the requirements of ISO 15638-4.
Data testing
The application service provider [4.27] shall monitor that each ‘stored data’ transfer occurs within the interval I determined by the jurisdiction [4.18].
The application service provider will conduct tests on all incoming IVS data records to ensure they are complete, consistent, and error-free, while also verifying the consecutive numbering of the records received.
An alarm will be triggered if any numbering sequence resets to a lower value, indicating that all numbers have been utilized The application service provider is responsible for ensuring that record numbers within IVS data increase chronologically and for verifying the integrity and authenticity of stored data Additionally, they must check that the distance between the last position record before a non-operational period and the first valid position record after it does not exceed 500 meters; if multiple non-operational periods occur, only one alarm will be activated Lastly, the provider must assess whether the IVS has been malfunctioning for more than seven consecutive days.
Application service providers have the discretion to determine how tests are conducted, ensuring that they meet the jurisdiction regulator's requirements for an adequate testing regime.
Data backup and archiving
Jurisdiction specification JS6: ‘Core Application Data’
The jurisdiction will identify additional data concepts beyond the basic vehicle data to establish the core application data requirements for their regulatory framework, supported by relevant legislation Core application data will always include the basic vehicle data as defined in ISO 15638-5 Furthermore, the jurisdiction must provide an application that can be accessed either dynamically through wireless communications, as outlined in ISO 15638-1 and ISO 15638-5, at the entry point or online prior to journeys, ensuring the onboard data pantry is equipped with the necessary data.
Essential information is crucial for supporting regulated application services and must always be included as part of the core application data in all circumstances.
[4.13] This data concept shall be known as the basic vehicle data [4.8] and is defined in ISO 15638-5 as the
TARV local data tree (LDT)
ISO 15638-5 provides specification of the content of the basic vehicle data [4.8] concept and the form and content of the LDT.
Jurisdiction specification JS7: ‘Basic Vehicle Data’
The jurisdiction [4.18] will establish the elected options related to the basic vehicle data [4.8] concept, which will be integrated into the core application data [4.13] framework This information will be accessible in the onboard data pantry of the IVS, and the necessary legislation or regulation will be provided to enforce this requirement.
OEM installed IVS
Regulation regime
The equipment shall be part of the vehicle original equipment and type approved [4.29] as part of the vehicle type approval.
Physical installation aspects
The physical configuration of the IVS is left to market discretion, potentially manifesting as a standalone onboard unit or, more commonly, as a software function integrated with the vehicle's databus, such as CAN or J1939, and possibly as part of an in-vehicle communications platform.
The installation of the IVS is integrated into the vehicle's manufacturing process, and it can either be included as a standard feature or chosen as an optional upgrade by the customer during the ordering phase.
The installation of the IVS involves integrating physical components into the vehicle, installing software and data into the operating system, and connecting to the vehicle's power supply It also includes commissioning external equipment and linking to common vehicle systems such as GNSS and GSM/UMTS SIM cards, potentially through the vehicle databus Additionally, the setup of the human machine interface (HMI) and the installation of antennas for wireless communication with infrastructure are essential In scenarios where the IVS is OEM-fitted, certain components may be shared with other applications, including wireless communication devices, GNSS, road map data, and the HMI.
Vehicle data bus
The physical form of the IVS is not specified and shall be a market place decision, however, in the case of an
OEM factory installed IVS during the manufacture of the vehicle, it is expected that the IVS will have (albeit limited) access to the vehicle CAN or J1939 databus.
Initial set-up
12.3.4.1 Service provider specification SP13: Prime service provider
The first service provider to enter into a contract with the user for a specific IVS-regulated commercial freight vehicle will be designated as the 'prime service provider.' This provider is responsible for the initial commissioning and ongoing maintenance of the IVS If the contract with the prime service provider is terminated for any reason, the user must select a new service provider to take on the role of prime service provider.
The service provider will notify the jurisdiction that it has assumed the role of the prime service provider for the designated IVS/regulated commercial freight vehicle combination, following the prescribed guidelines set by the jurisdiction.
The prime service provider [4.21] shall be responsible for the maintenance of the IVS and any related TIDs, and for the transmission and back-up of ‘stored data’
The prime service provider [4.21] shall program the IVS memory with the IPv6 address of the prime service provider, in the form prescribed in ISO 15638-5
12.3.4.2 Service provider specification SP14: Set access conditions
The initial contracted service provider, followed by the prime service provider, will establish the access conditions and determine who is authorized to read or write to the IVS memory.
12.3.4.3 ‘Approval Authority’ specification AA6: vehicle unique identification
The approval authority will assign a unique identification number or code to each regulated commercial freight vehicle This identification may be accessible to the vehicle operator or approved service providers, depending on the jurisdiction's regime For guidance on suitable coding systems, refer to Annex B of ISO 15638.
12.3.4.4 Service provider specification SP15: IVS unique identification
When delivering a vehicle to the user, it is likely that the approval authority has not yet issued a unique identification number The first contracted service provider will assign a unique and clear identification to the IVS, either at the time of manufacture or during the service process, as specified by the jurisdiction Additionally, the service provider is responsible for storing both the identification code of the registered commercial freight vehicle and the unique IVS identity in the IVS's memory.
12.3.4.5 Service provider specification SP16: ‘Basic Vehicle Data’
The first contracted service provider [4.27] shall commit the permanent elements of the basic vehicle data [4.8]
(as defined in ISO 15638-5) of the registered commercial freight vehicle to the memory of the IVS.
Aftermarket installed IVS
Regulation regime
The IVS shall be type approved [4.29] by the approval authority [4.4] or shall be self-certified according to the regime of the jurisdiction [4.18].
Physical installation aspects
The physical design of the IVS is left to market discretion, but it is likely to start as a discrete stand-alone unit (OBU) equipped with internal functions like GNSS and connections to external systems such as tachographs.
In this scenario, the installation of the IVS is undertaken as part of the first contracted service provider [4.27] contract
The unit that houses the IVS functionality will have already been type approved [4.29] or self-certified See
14, and 8.8.5) The installing service provider [4.27] takes the responsibility to ensure that the equipment is correctly installed and functioning properly.
The installation of the IVS involves integrating its physical components into the vehicle, installing necessary software and data into the operating system, and connecting it to the vehicle's power supply Additionally, it requires the commissioning of external equipment and IVS features, such as GNSS and GSM/UMTS SIM cards Since the IVS may not have access to the vehicle databus, it typically includes equipment to provide essential vehicle data, known as 'Core Application Data.' However, if the vehicle manufacturer allows access to the databus, the IVS can utilize that data as well.
Certain jurisdictions may require that for vehicle type approval or registration, regulated vehicles must provide specific data or have designated manufacturer-fitted equipment that can connect to the IVS.
The service provider [4.27] is tasked with the installation and commissioning of the human machine interface (HMI) and ensuring the connection to antennas for wireless communication within the infrastructure.
Vehicle data bus
The physical design of the IVS is left to market discretion, as outlined in ISO 15638, which also assumes that the IVS may lack access to the vehicle databus.
Initial set-up
12.4.4.1 Service provider specification SP18: Prime service provider
The service provider responsible for installing the IVS in a regulated commercial freight vehicle must operate under a contract with the user and will take on the role of the 'prime service provider.' This prime service provider is tasked with the initial commissioning and ongoing maintenance of the IVS If the contract between the prime service provider and the user is terminated for any reason, the user must select a new service provider and establish a contract with them to assume the role of the prime service provider.
To establish itself as the primary service provider, the service provider must inform the jurisdiction, as required, upon installation and commissioning, that it has assumed this role for the designated IVS/regulated commercial freight vehicle combination.
The prime service provider [4.21] shall be responsible for the maintenance of the IVS and any related TIDs, and for the transmission and back-up of ‘stored data’
The prime service provider [4.21] shall program the IVS memory with the IPv6 address of the prime service provider, in the form prescribed in ISO 15638-5
12.4.4.2 Service Provider specification SP19: Set access conditions
The initial contracted service provider, along with the primary service provider, will establish the access conditions and determine who is authorized to read or write to the IVS memory.
12.4.4.3 ‘Approval Authority’ specification AA7: regulated commercial vehicle unique identification
The approval authority will assign a unique identification number or code to each regulated commercial freight vehicle This identification may be accessible to the vehicle operator or approved service providers, depending on the jurisdiction's regime For guidance on suitable coding systems, refer to Annex B of ISO 15638.
12.4.4.4 Service provider specification SP20: IVS unique identification
The service provider responsible for installing the IVS must assign a permanent unique identification to the system, either during installation or at the time of manufacture Additionally, the provider is required to store both the identification code of the registered commercial freight vehicle and the unique IVS identity in the IVS memory.
12.4.4.5 Service provider specification SP21: ‘Basic Vehicle Data’
The service provider responsible for installing the IVS must ensure that the permanent elements of the basic vehicle data, as specified in ISO 15638-5, are committed to the memory of the IVS for the registered commercial freight vehicle.
12.4.4.6 Service provider specification SP22: ‘Core Application Data’
The service provider [4.27] installing the IVS shall commit the permanent elements of the core application data
[4.13] (as determined by the jurisdiction) of the registered commercial freight vehicle to the memory of the IVS.