| C2C-CC |
RS 2080 |
1.6.5 |
Automotive Requirements for the Infrastructure to Vehicle Information (IVI) Service |
The present document provides requirements related to the features of a C-ITS station transmitting IVIM to enable interoperability. The requirements in this document are intended as an addition to existing requirements in [ISO 19321], [ETSI TS 103 301] and the C-Roads profile.
In this document only, highway use cases were considered, use cases on other road types or in urban areas may need different profiling. Apart from that, the requirements in this document are independent of the specific use case and shall therefore apply to all highway use cases of the InVehicle-Signage Service.
Furthermore, the requirements are focused on the functional level, specifications on the lower communication levels are out of scope of this document. Also, for the functional level, these requirements don’t claim to be complete.
The requirements in this document for now only apply to road traffic signs and signages that are physically represented on the road (through analogue or digital displays). For the future consideration of signs, which are not physically present (i.e. only virtual), the requirements will need to be reconsidered and adapted where needed. In addition, all requirements only refer to signs as listed in [ISO 14823], i.e. signs which are mounted on a pole or digital display. This excludes the use of subpanels that are not explicitly listed in [ISO 14823], such as subpanels with text in a local language. This explicitly excludes any kind of lane marking.
In some cases, requirements are written in a way which let the implementation open, for example if they refer to very specific implementations which may depend on specific national regulations. Those requirements have to be further detailed by anybody implementing that requirement. Beside these special requirements all other requirements can be further detailed, too.
At the time of the latest release of this document, the ISO standard on IVIM was still under revision. Part of this revision is the addition of a data field ‘segmentExtended’ which allows among others to indicate (asymmetric) segment widths and to ‘concatenate’ zones. There already exist intentions to adapt corresponding requirements to this new concept as soon as the new standard revision is published.
|
15/12/2023 |
Published |
Connectivity |
Link |
| SSC |
TR 68-1 |
1.0 |
Autonomous vehicles – Part 1 : Basic behaviour |
This TR gives the provisions relating to the dynamic driving task (DDT) and behaviour controlled by an AV’s automated driving system (ADS). The scope is as follows:
a) Conduct of autonomous driving, including but not limited to vehicle-to-vehicle interactions;
b) Interpretation of road signs, markings and traffic signals; and
c) Management of non-transferable rules.
This TR covers the key directives, providing safety and maintaining traffic movement, for automated driving and provides a hierarchy of directives and rules to overcome potential conflicts between rules. It introduces a framework for the application of rules as part of a driving policy. The TR also discusses the current capability limitations of AVs and accounts for a continual process of improvement, which includes the refinement of the rulebook and scenario database.
The following are not covered in this TR and may be considered in future revisions:
a) The interface between an AV and any occupants including the human safety driver;
b) Rules relating to non-driving tasks and longer term tactical cognitive functions such as route planning; and
c) Communication or signalling between the AV and external stakeholders including but not limited to pedestrians and other drivers, which extends beyond use of standard vehicle equipment, including lighting and horn, as described in existing driving rules.
There are substantial references to Singapore’s Basic Theory of Driving (BTD) and Final Theory of Driving (FTD) throughout this TR. Where applicable the relevant items of the BTD/FTD are linked in brackets. For example “(BTD 1)” refers to item number 1 of the BTD.
|
31/01/2019 |
Published |
Management/ Engineering Standards |
Link |
| SSC |
TR 68-2 |
1.0 |
Autonomous vehicles – Part 2 : Safety |
The purpose of this TR is to give the safety provisions for autonomous vehicles (AVs) deployed on public roads. Specifically, the use case of deployment in Singapore is considered.
The TR can be subdivided into two major fields:
a) Design and production quality; and
b) Safe operation in the context of specific applications in Singapore.
To stipulate system-level safety in order to ensure:
a) functional and operational safety requirements of vehicles are met;
b) system safety is applicable to the operation design domain in which the vehicle operates;
c) the vehicle developer, system integrator and system operator are competent organisations with an appropriate quality management system in place supported by competent personnel; and
d) that appropriate safety goals are in place to guide safety assurance at the system level.
The TR does not differentiate between vehicles being built from scratch and conventional homologated vehicles, which have been equipped with additional driving automation system/technology (see SAE J3016_201806) to increase the supported level of driving automation within SAE's scale.
|
31/01/2019 |
Published |
Management/ Engineering Standards, Safety |
Link |
| SSC |
TR 68-3 |
1.0 |
Autonomous vehicles – Part 3 : Cybersecurity principles and assessment framework |
The purpose of this TR is to provide a Technical Reference for cybersecurity assessment framework of Autonomous Vehicles deployed on public roads. Specifically, the use case of deployment in Singapore is considered.
This TR normatively references existing standards relevant to automotive safety and cybersecurity, as listed in Clause 2. Its aim is to coordinate and extend the referenced standards to cover the following areas:
- Apply methodology from existing cybersecurity standards and best practices in the context of automotive practices. Where the subject is a cyber-physical vehicle system that includes embedded control systems, and a coupling between the computational elements and physical elements. Furthermore, the subject system has close physical interactions with people and other vehicles while deployed on public roads.
- Extend existent cybersecurity standards and best practices for automotive application to provide an enhanced cybersecurity safeguard in response to the increased security threat potential which is present for vehicles deployed to level 4/5 automation (as defined in SAE J3016_2018) where a human operator is not present in the vehicle to intervene in the event that an attack has compromised it.
The assessment framework takes a threat and risk-based approach and includes a security risk assessment. However, the scope of this TR does not extend to consider risks arising due to any consequential impacts to the physical operation of the vehicle arising from cybersecurity. TR 68: Part 2 should be referred to for further discussion on AV system safety.
Specifically, with reference to Figure 1, the scope of assessment defined in this TR includes the following vehicle zones (and their connected communication channels) that are within the Vehicle Intelligence and Interface Layer:
- Vehicle intelligence zone;
- Device zone;
- HMI zone.
Other zones are considered to be adequately covered by existing standards, or not critical to the safe operation of the AV. As such, zones falling within the following layers are excluded from the scope, but currently not limited to the following:
- Traffic infrastructure layer;
- Vehicle actuation layer.
Key areas of focus for this TR include:
- Approach of an enhanced AV cybersecurity assessment framework;
- Identify potential attack surfaces and threat scenarios; and
- Framework and methodology for AV security testing.
Two tiers of cybersecurity safeguards are set out in this TR. The first tier is set out in Clause 5 where cybersecurity principles are presented for AV developers/operators to manage cybersecurity for the full lifecycle of the AV. The second tier is set out in Clause 6 where a framework for the independent cybersecurity assessment of AV systems is presented.
The fields of automated vehicles and cybersecurity are both experiencing intensive development with new standards and technology developments being released regularly. Therefore, it is likely that this TR will be regularly reviewed and updated to align with industry developments.
|
08/01/2019 |
Published |
Cybersecurity |
Link |
| SSC |
TR 68-4 |
Ed. 1 |
Autonomous vehicles – Part 4 : Vehicular data types and formats |
This TR is written for level 4 and level 5 AVs, as defined in SAE J3016, to be deployed as people and goods mover systems (i.e. mobility-on-demand and scheduled transportation services that are equivalent to Class 3 and Class 4 motor vehicle driving licenses in Singapore). This TR is applicable to level 4 and level 5 AVs in mixed-use traffic and on public roads. Hence, the safety of internal occupants and external road users is paramount.
This TR specifies vehicular data types and formats (but not the interchange syntax) for the following purposes:
a) Data to be recorded by the data storage system for automated driving;
b) Reasonable and adequate use of AV data to continuously improve safety;
c) Management of dynamic content (e.g. high-definition (HD) mapping, road traffic information);
d) Data to be used in investigation and reporting of accidents and claim disputes; and
e) V2X (vehicle to everything) information exchange for enhancing safety and efficiency.
This TR is based on the premise that to send, retrieve, return and track messages on a shared platform, a common communication and messaging protocol should be observed. This TR sets out the formats in which data elements should be recorded and/or relayed only; and it does not mandate data provision between or among any actors/entities. It also does not cover data ownership and privacy.
The scope of the TR excludes the following:
a) Over-the-air software updates;
b) AV fleet management system;
c) Interface between AV and any human operator/driver; and
d) Data privacy and ownership.
The meaning of automation driving levels, automated driving system (ADS), operational design domain (ODD) and dynamic driving task (DDT) are as defined in SAE J3016.
|
14/06/2021 |
Published |
In-Vehicle Systems, Networks, Data and Interface Definition, Safety |
Link |
| SAE |
AVSC00007202107 |
Ed. 1 |
AVSC Information Report for Adapting a Safety Management System (SMS) for Automated Driving System (ADS) SAE Level 4 and 5 Testing and Evaluation |
This document shares information on a Safety Management System (SMS) framework in the context of ADS testing and evaluation operations. This report was developed to provide ADS organizations information about the role of organizational safety, which may be considered in the ADS testing and evaluation process. The SMS framework represents a method used in non-automotive industries (e.g., aviation, rail, nuclear) with the goal of enhancing an organization’s operational safety performance.
|
01/07/2021 |
Published |
Safety, Testing, Verification & Validation |
Link |
| SAE |
IAMTS0001202104 |
Ed. 1 |
Best Practice for A Comprehensive Approach for the Validation of Virtual Testing Toolchains |
This white paper by the International Alliance for Mobility Testing and Standardization (IAMTS) is the first release of an ongoing effort to develop best practices for validating virtual testing of automated driving systems (ADSs). It provides a best practices approach for validating simulation testing against physical baselines for the purposes of validation/homologation of an ADS. This approach is presented in four steps with examples of their application and an explanation of further work being pursued on this topic. This publication is funded by IAMTS members and is provided free of charge to the public.
|
01/04/2021 |
Published |
Testing, Verification & Validation |
Link |
| SAE |
AVSC-I-04-2023 |
Ed. 1 |
Best Practice for ADS Remote Assistance Use Case |
Automated driving system-dedicated vehicles (ADS-DVs) can handle a wide variety of circumstances they might encounter on the road. When circumstances are encountered that exceed ADS design capabilities, the ADS is designed to bring the vehicle into a minimal risk condition (MRC). When an ADS-DV encounters these conditions—identified as “triggers” within this best practice—they can request remote assistance (RA) from a remotely located human operator. RA involves the provision of guidance, suggestions, or recommendations to a vehicle from a remote location, without direct control of the vehicle. RA has emerged as a useful tool in supporting the operation of an ADS. It can complement the capabilities of ADS-DVs and improve overall system performance and utilization, particularly in situations that exceed ADS design capabilities.
This best practice provides guidelines for integrating remote assistance within the context of ADS. It describes the distinct functions and tasks of RA, aims to clear the confusion between remote assistance and remote driving, and makes suggestions on training to be considered. In addition, this document presents a high-level process of implementing RA, gives examples of triggers that may prompt RA when ADS design capabilities have been exceeded, and illustrates a non-exhaustive list of possible data elements that may be used to provide assistance to the ADS.
By having a clear understanding of the nature, function, and scope of the RA, ADS developers and operators can help to ensure that RA is safer, more reliable, and more effective in ADS-equipped vehicles.
|
28/11/2023 |
Published |
Management/ Engineering Standards |
Link |
| SAE |
AVSC00011202307 |
Ed. 1 |
Best Practice for Continuous Monitoring and Improvement after Deployment |
Successful scaling of automated driving system (ADS) technology and realization of its full potential will require developers and service providers to continuously monitor performance of their fleet and enact prompt improvements should issues arise. ADS developers and manufacturers can use the data collected from vehicles in active deployments (e.g., safety performance data) to proactively confirm initial risk assumptions and feed other safety management processes. This best practice provides an approach to continuous monitoring and potential improvement of safety performance of ADS-DVs after deployment.
It also outlines approaches to analyzing data related to known and unknown variations in the ADS-DV’s operating environment and complements other AVSC best practices that provide metrics and methods which can be used to monitor safety [AVSC00006202103, AVSC00008202111] while considering important factors pertaining to how data is collected, analyzed, and used [AVSC00004202009].
|
25/07/2023 |
Published |
Management/ Engineering Standards, Safety |
Link |
| SAE |
AVSC00004202009 |
Ed. 1 |
Best Practice for Data Collection for Automated Driving System-Dedicated Vehicles (ADS-DVs) to Support Event Analysis |
As technology and functionality of vehicle systems change, so do data recording needs. In ADS-dedicated vehicles (DV), the ADS perceives the environment and handles vehicle motion control, i.e., the dynamic driving task (DDT), as described in SAE J3016. When an ADS takes the place of a human driver, its sensing, processing, and control systems necessitate new considerations for data recording. Data recording is important to crash reconstruction, system performance investigations, and event analysis. It enables industry-wide improvements in ADS safety. This best practice makes recommendations for the ADS-DV data needed to support: (1) information about what the ADS 'saw' and 'did' and (2) identify the technology-relevant factors that contributed to the event.
The Best Practice for Data Collection for Automated Driving System Dedicated Vehicles (ADS-DVs) to Support Event Analysis makes recommendations for the collection, storage, and retrievability of onboard motor vehicle ADS event data. A list of 39 data elements are recommended for ADS-DVs to collect, including 14 new elements specific to ADS-DVs and 25 elements either previously defined or adapted from legacy standards in data collection.
|
23/09/2020 |
Published |
In-Vehicle Systems, Networks, Data and Interface Definition, Management/ Engineering Standards |
Link |