SIST-TS CEN/TS 17875:2023
(Main)Intelligent transport systems - eSafety - Incident Support Information System (ISIS) Architecture
Intelligent transport systems - eSafety - Incident Support Information System (ISIS) Architecture
This document describes the architecture of a secure process flow between a source ITS system and a destination ITS system to provide an ‘incident support information system’ (ISIS) to emergency responders by accessing (with the agreement of the vehicle owners/keepers) data from a crashed vehicle and/or other vehicles, or drones, in the vicinity of the incident.
Intelligente Verkehrssysteme - ESicherheit - Abstützen bei Vorfällen Informationssystem (ISIS) Architektur
Dieses Dokument beschreibt die Architektur eines sicheren Prozessablaufs zwischen einem ITS-Quellsystem und einem ITS-Zielsystem, um den Einsatzkräften ein Nach-eCall-Vorfall-Unterstützungsinformationssystem (en: ISIS, Incident Support Information System) zur Verfügung zu stellen, das (mit Zustimmung der Fahrzeugeigentümer/-halter) auf Daten eines verunglückten Fahrzeugs und/oder anderer Fahrzeuge oder Drohnen in der Nähe des Unfalls zugreift.
Systèmes de transport intelligents - eSafety - Architecture du système d'information sur la prise en charge des incidents (ISIS)
Inteligentni transportni sistemi - e-Varnost - Arhitektura informacijskega sistema za podporo incidentom (ISIS)
Ta dokument opisuje arhitekturo varnega poteka procesov med izvornim sistemom inteligentnega transportnega sistema in ciljnim sistemom inteligentnega transportnega sistema za zagotavljanje »informacijskega sistema za podporo pri nezgodah« (ISIS) za prve posredovalce pomoči prek dostopa (ob sklenjeni pogodbi z lastniki/imetniki vozila) do podatkov iz vozila, vpletenega v nesrečo in/ali drugih vozil ali dronov v bližini nezgode.
General Information
Standards Content (Sample)
SLOVENSKI STANDARD
SIST-TS CEN/TS 17875:2023
01-maj-2023
Inteligentni transportni sistemi - e-Varnost - Arhitektura informacijskega sistema
za podporo incidentom (ISIS)
Intelligent transport systems - eSafety - Incident Support Information System (ISIS)
Architecture
Intelligente Verkehrssysteme - ESicherheit - Abstützen bei Vorfällen Informationssystem
(ISIS) Architektur
Systèmes de transport intelligents - eSafety - Architecture du système d'information sur
la prise en charge des incidents (ISIS)
Ta slovenski standard je istoveten z: CEN/TS 17875:2022
ICS:
03.220.20 Cestni transport Road transport
13.200 Preprečevanje nesreč in Accident and disaster control
katastrof
35.240.60 Uporabniške rešitve IT v IT applications in transport
prometu
SIST-TS CEN/TS 17875:2023 en,fr,de
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.
---------------------- Page: 1 ----------------------
SIST-TS CEN/TS 17875:2023
---------------------- Page: 2 ----------------------
SIST-TS CEN/TS 17875:2023
CEN/TS 17875
TECHNICAL SPECIFICATION
SPÉCIFICATION TECHNIQUE
December 2022
TECHNISCHE SPEZIFIKATION
ICS 03.220.20; 13.200; 35.240.60
English Version
Intelligent transport systems - eSafety - Incident Support
Information System (ISIS) Architecture
Systèmes de transport intelligents - eSafety - Intelligente Verkehrssysteme - ESicherheit - Abstützen
Architecture du système d'information sur la prise en bei Vorfällen Informationssystem (ISIS) Architektur
charge des incidents (ISIS)
This Technical Specification (CEN/TS) was approved by CEN on 30 October 2022 for provisional application.
The period of validity of this CEN/TS is limited initially to three years. After two years the members of CEN will be requested to
submit their comments, particularly on the question whether the CEN/TS can be converted into a European Standard.
CEN members are required to announce the existence of this CEN/TS in the same way as for an EN and to make the CEN/TS
available promptly at national level in an appropriate form. It is permissible to keep conflicting national standards in force (in
parallel to the CEN/TS) until the final decision about the possible conversion of the CEN/TS into an EN is reached.
CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia,
Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway,
Poland, Portugal, Republic of North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Türkiye and
United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION
EUROPÄISCHES KOMITEE FÜR NORMUNG
CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2022 CEN All rights of exploitation in any form and by any means reserved Ref. No. CEN/TS 17875:2022 E
worldwide for CEN national Members.
---------------------- Page: 3 ----------------------
SIST-TS CEN/TS 17875:2023
CEN/TS 17875:2022 (E)
Contents Page
Introduction . 4
1 Scope . 6
2 Normative references . 6
3 Terms and definitions . 6
4 Symbols and abbreviations . 8
5 Conformance . 9
6 Phases of the ISIS. 9
6.1 Summary of phases . 9
6.2 Phase 1: Instigation . 10
6.3 Phase 2: Initiation . 11
6.3.1 Nature of the Communication . 11
ISO 5616 “ITS Secure Interface” architecture . 11
6.3.2 Architectural Foundation of the “Secure ITS Data Management and Access Interface”
. 11
6.3.3 Global Transport Data Format . 16
6.3.4 ISIS in the context of the Secure Interface for data access . 17
6.3.5 Security Authentication . 19
6.3.6 Call establishment . 29
6.4 Phase 3: Multiple Provider Management . 29
6.5 Phase 4: Establish capability . 30
6.6 Phase 5: Search and offering . 30
6.7 Phase 6: Data/service provision . 30
6.8 Phase 7: Shutdown provisions . 30
6.9 Phase 8: Terminate ISIS . 30
7 Service Provision Architecture . 31
Bibliography . 33
2
---------------------- Page: 4 ----------------------
SIST-TS CEN/TS 17875:2023
CEN/TS 17875:2022 (E)
European foreword
This document (CEN/TS 17875:2022) has been prepared by Technical Committee CEN/TC 278
“Intelligent transport systems”, WG15 eSafety, the secretariat of which is held by NEN.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CEN shall not be held responsible for identifying any or all such patent rights.
Any feedback and questions on this document should be directed to the users’ national standards body.
A complete listing of these bodies can be found on the CEN website.
According to the CEN/CENELEC Internal Regulations, the national standards organisations of the
following countries are bound to announce this Technical Specification: Austria, Belgium, Bulgaria,
Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland,
Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Republic of
North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Türkiye and the
United Kingdom.
3
---------------------- Page: 5 ----------------------
SIST-TS CEN/TS 17875:2023
CEN/TS 17875:2022 (E)
Introduction
A 112-eCall is an incident alert system, specified in Regulation 305/2013/EC and Regulation
758/2015/EC, which specify that the 112-based eCall in-vehicle system “ ‘eCall’ means an in-vehicle
emergency call to 112, made either automatically by means of the activation of in-vehicle sensors or
manually, which establishes a 112-based audio channel between the occupants of the vehicle and a PSAP
over which it sends a minimum set of data as defined in EN 15722 to the PSAP and subsequently opens the
audio channel for dialogue between the PSAP and the occupants of the vehicle”. The PSAP instigates
response by sending emergency responders to the scene, talks with the occupants of the vehicle if
possible, and at some point at the PSAP’s choosing, terminates the eCall.
A 112-eCall is described as an incident alert system, because
a) it is a call between a vehicle and a Public Service Answering Point;
b) Regulation 758/2015 specifies (Article 6 (8)) that “The MSD sent by the 112-based eCall in-vehicle
system shall include only the minimum information as referred to in the standard EN 15722: ‘Intelligent
transport systems — eSafety — eCall minimum set of data (MSD)’. No additional data shall be
transmitted by the 112-based eCall in-vehicle system, “; and
c) Regulation 758/2015 further specifies (whereas (15)) Manufacturers shall ensure that the 112-based
eCall in-vehicle system and any additional system providing TPS eCall or an added-value service are
designed in such a way that no exchange of personal data between them is possible.
eCall therefore, by Regulatory definition, terminates once emergency responders have been activated and
the PSAP elects to terminate the call (in some circumstances that may only be when the responders arrive
on the scene of the incident, but in most cases, well before).
EU CEF Project sAFE, and CEF Project I-HeERO before it, identified that as in-vehicle technology advances,
new opportunities to provide additional helpful data to emergency responders arise. Data from cameras
and sensors can be of significant assistance to emergency responders. Project iHeERO identifies:
— Additional sensor information could be
— Cameras (video or still image)
— Special sensors e.g. gas or leakage
— Passenger detection sensors
and
1. PSAP operator initiates a query to get a list of all accessible data sources (including sensors) on the
vehicl
2. The IVS accepts the request and posts all available data sources including sensors
3. PSAP notes that an internal camera in the cabin is available for query
But does not say how this is to be achieved. We know that because of the Regulation, it will not be
achieved by the PSAP in the eCall, and Activity (3.6) of project sAFE has identified that
a) The crucial participants to this action are the affected vehicle (and its occupants) and the ‘emergency
responders’ – the paramedic and police etc., who arrive on the scene to handle the incident (not the
PSAP [although in some 112 response configurations the level 1 PSAP may remain in contact or
control until the incident is concluded]).
4
---------------------- Page: 6 ----------------------
SIST-TS CEN/TS 17875:2023
CEN/TS 17875:2022 (E)
b) This information support is not an eCall, but a post eCall incident support activity between the
emergency responders and vehicles at the scene of the incident and their occupants.
It is further observed, though not elsewhere commented in the main body of the sAFE project report, that
aerial drones are increasingly being used to provide information to emergency responders. Providing the
opportunity to link these devices with these other new capabilities therefore also makes sense.
However, rather than a loose indication of what might happen next, this document proposes the
architecture to provide an ‘Incident Support Information System’ ISIS.
The objective of the ISIS at the highest level is shown in Figure 1.
Figure 1 — ISIS −1 – Architecture - Objective
5
---------------------- Page: 7 ----------------------
SIST-TS CEN/TS 17875:2023
CEN/TS 17875:2022 (E)
1 Scope
This document describes the architecture of a secure process flow between a source ITS system and a
destination ITS system to provide an ‘incident support information system’ (ISIS) to emergency
responders by accessing (with the agreement of the vehicle owners/keepers) data from a crashed vehicle
and/or other vehicles, or drones, in the vicinity of the incident.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO/DIS 21177, Intelligent transport systems — ITS-station security services for secure session
establishment and authentication between trusted devices
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
• IEC Electropedia: available at https://www.electropedia.org/
• ISO Online browsing platform: available at https://www.iso.org/obp
3.1
bounded secured managed domain
ITS-stations
Note 1 to entry: The ITS-station concept provides for secure peer-to-peer communications between entities that
are themselves capable of being secured and remotely managed; while this is an abstract definition, it has very
specific physical consequences; the bounded nature is derived from the requirement for ITS-stations to be able to
communicate amongst themselves, i.e. peer-to-peer, as well as with devices that are not secured; realising that to
achieve this in a secure manner often requires distribution and storage of security-related material that must be
protected within the boundaries of the ITS-station, leads to the secured nature of the entity; thus ITS-stations are
referred to as bounded secured managed domains (BSMD).
3.2
data
representations of static or dynamic objects in a formalized manner suitable for communication,
interpretation, or processing by humans or by machines
Note 1 to entry: In packet switched networks, voice is carried in packets of data.
3.3
data concept
any of a group of data structures (i.e. object class, property, value domain, data elements, message,
interface dialogue, association) referring to abstractions or things in the natural world that can be
identified with explicit boundaries and meaning and whose properties and behaviour all follow the same
rules
6
---------------------- Page: 8 ----------------------
SIST-TS CEN/TS 17875:2023
CEN/TS 17875:2022 (E)
3.4
data element
single unit of information of interest (such as a fact, proposition, observation, etc.) about some (entity)
class of interest (e.g. a person, place, process, property, concept, state, event) considered to be indivisible
in a particular context
3.5
eCall
emergency call which is generated either automatically via activation of in-vehicle sensors or manually
by the vehicle occupants (or person(s) riding on a vehicle that is not fitted with an enclosed compartment
and/or (a) seatbelt(s)), and which, when activated, provides notification and relevant location
information to the most appropriate 'Public Safety Answering Point’, by means of mobile wireless
communications networks, carries a defined standardized ‘Minimum Set of Data’ [MSD] notifying that
there has been an incident that requires response from the emergency services, and establishes an audio
channel between the occupants of the vehicle and the most appropriate 'Public Safety Answering Point’
3.6
GeoAnycast
as defined in ETSI TS 102 636-2
Note 1 to entry:
GEOANYCAST 3 Geographically-Scoped Anycast (GAC)
GEOANYCAST_CIRCLE 0 Circular area
GEOANYCAST_RECT 1 Rectangular area
GEOANYCAST_ELIP 2 Ellipsoidal area
GEOBROADCAST 4 Geographically-Scoped
3.7
global transport data format
function of data conversion of sensor and control network raw data in a flexible way, using configuration
data specific for the sensor and control network connected to them
Note 1 to entry: This technical solution is specified in ISO/TS 21184 which addresses the complexity of converting
protocol data units with raw (device-specific) data of any sensor and control network, of any kind of technical
equipment, into a standardized data format, which it defines as global transport data format (GTDF); the advantage
of the configuration concept is the flexibility to use the same implementation architecture for different sensor and
control networks.
3.8
Intelligent transport system
information, communication and control systems in the field of urban and rural surface transportation,
including intermodal and multimodal aspects thereof, traveller information, traffic management, public
transport, commercial transport, emergency services and commercial services in the transport systems
sector
7
---------------------- Page: 9 ----------------------
SIST-TS CEN/TS 17875:2023
CEN/TS 17875:2022 (E)
3.9
ITS-station
functional entity comprised of an ITS-station facilities layer, ITS-station networking & transport layer,
ITS-station access layer, ITS-station management entity, ITS-station security entity and ITS-station
applications entity providing ITS services
Note 1 to entry: From an abstract point of view, the term “ITS-station” refers to a set of functionalities. The term is
often used to refer to an instantiation of these functionalities in a physical unit. Often the appropriate interpretation
is obvious from the context. The proper name of physical instantiation of an ITS-station is ITS-station unit (ITS-
station).
3.10
latency
latency from a general point of view is a time delay between the cause and the effect of some physical
change in the system being observed; latency is a time interval between the input to a simulation and the
visual or auditory response, often occurring because of network delay in two way communications where
the lower limit of latency is determined by the medium being used to transfer information – c in two-way
communication systems, latency is the delay between transmission and the ability to use information
received from that transmission. The latency being caused by processing speed, transmission speed,
processing delays, transmission delays, available bandwidth, transmission and security protocols and
processes, etc
3.11
low latency
implication of few if any latency delays providing more or less immediate transmission, usability, and
ability to respond/react
4 Symbols and abbreviations
112 European emergency call number
AP DU application data unit
C-ITS cooperative ITS (also known as ‘connected vehicle’0
CAN control area network (ISO 11898-1)
CANBUS control area network data-bus (ISO 11898-1)
CANBUS ID control area network data-bus node identifier (ISO 11898-1)
CAV connected or automated vehicle
CCAM cooperative connected and automated mobility
EC European Commission
ECU electronic control unit
EENA European Emergency Number Association
EU European Union
GDPR General Data Protection Regulation (EU 2016/679)
GDTF global transport data format (ISO/TS 21184)
I_HeERO Infrastructure Harmonized eCall European Pilot (CEF Project)
IPv6 internet protocol
8
---------------------- Page: 10 ----------------------
SIST-TS CEN/TS 17875:2023
CEN/TS 17875:2022 (E)
ISIS incident support information system
ITS Intelligent transport system
IVS in-vehicle system
LLC link layer control
MAC Medium access control
MSD minimum set of data (EN 15722)
OAD optional additional data (EN 15722)
OSI Open Systems Interconnection, (ISO/IEC 7498-1)
PSAP Public Safety Answering Point
RPM revolutions per minute
sAFE Safe Aftermarket eCall (EU CEF Project)
SAP DU service announcement protocol data unit
SI secure interface
SVI secure vehicle interface
TLS transport layer security
TPS third party service
TS Technical Specification
VOIP voice over internet protocol
VRU vulnerable road user
5 Conformance
ISIS systems operate using the ISO 21217 ITS Intelligent transport systems — Station and communication
architecture with cybersecurity as defined in ISO/DIS 21177 and within the ITS data governance
paradigm defined in ISO TS 5616 (draft), so it is a prerequisite that ISIS systems are in conformance with
these systems in every respect.
6 Phases of the ISIS
6.1 Summary of phases
Phase 1: Instigation
Phase 2: Initiation
Phase 3: Multiple Provider Management
Phase 4: Establish Capability
Phase 5: Search and Offering
Phase 6: Data/service Provision
Phase 7: Shutdown Management
9
---------------------- Page: 11 ----------------------
SIST-TS CEN/TS 17875:2023
CEN/TS 17875:2022 (E)
Figure 2 — ISIS-2 – Process flow
Figure 2 illustrates, at a very high level, an ISIS system process flow where the emergency responder is
receiving data from multiple sources. These may be multiple sources within on vehicle, may be streams
from different vehicles, or a combination of both.
The following subClauses describe ISIS at an architectural level, and do not purport to be a system
specification.
6.2 Phase 1: Instigation
Instigation of the ISIS shall always be to the command of the lead emergency responder or his nominee.
a) Instigation will be at the actuation of the emergency responder carrying out a search for vehicles at
the incident location (a GeoAnycast according to ETSI TS 102 636-2) who are prepared to share their
camera/sensor data with emergency responders (on a confidential basis with privacy rights
respected); or
b) Instigation will be at the actuation of the emergency responder having received an ISIS consent
request (in the form of an OAD* message transmitted in the MSD sent to the PSAP as part of a
112-eCall, or as a result of dialogue between the PSAP and the occupants of the vehicle**).
10
---------------------- Page: 12 ----------------------
SIST-TS CEN/TS 17875:2023
CEN/TS 17875:2022 (E)
NOTE 1 * This requires a standards deliverable (similar to that for the optional ‘linked mobile phone number’
CEN/TS 17363) where the vehicle owner/keeper is given a set-up option to provide camera and sensor data to
emergency responders to assist the rescue process.
NOTE 2 * This will probably require a procedure to be determined by EENA and circulated to PSAPs. Project
sAFE will outreach to EENA in this regard.
6.3 Phase 2: Initiation
6.3.1 Nature of the Communication
The nature of the communication and its initiation are determined in this Clause. By definition, vehicles
that have the capability to send video and sensor data are so called “connected” vehicles capable of so-
called “C-ITS” cooperative ITS communications (sometimes called CAV or CCAM) that therefore already
have the capability – hardware and software - to support the ISIS. It is the objective of this document to
describe at a high level the architecture of how this already specified technology can be used to provide
the ISIS. This document does not provide a detailed system specification.
The nature of the data will be defined as ‘personal’ data by the definition of General Data Protection
Regulation (EU GDPR) 2016/679, so must be selectively addressable (i.e. only authorized data, and not
all data, can be accessed by the ISIS) and must be cybersecure.
ISO 5616 (in development by ISO TC204 WG19, working drafts available) provides such a mechanism.
Within that governance, selective access and cybersecurity, combined with the fact that connected
vehicles will already have the hardware/software to support such communications, mean that it is logical
and efficient to use this facility for ISIS communications, with the consequence that that the ISIS can be
provided without any additional hardware requirement for participating vehicles (and a low additional
hardware requirement for the emergency responder). 6.3.2 describes its generic architecture and how it
achieves these features.
ISO 5616 “ITS Secure Interface” architecture
The organisational structure of the Governance process of the “Secure ITS Data Management and Access
Interface” is defined in ISO 5616: Intelligent transport systems — ITS data management and access—
Governance using secure interfaces: high level specifications and supporting information resource”.
In this subclause, attention is directed towards the process flow of typical transactions to obtain or
provide ISIS data using the “Secure ITS Data Management and Access Interface” (SI) in accordance with
ISO 5616 / ISO/DIS 21177 / ISO 21217 with the support of ISO/TS 21184 and ISO/TS 21185.
6.3.2 Architectural Foundation of the “Secure ITS Data Management and Access Interface”
At the foundation of the process is the ISO 21217 ITS-station architecture. See Figure 3.
11
---------------------- Page: 13 ----------------------
SIST-TS CEN/TS 17875:2023
CEN/TS 17875:2022 (E)
(Source: ISO 21217:2020)
Figure 3 — SI-1 – Simplified ITS-station reference architecture
The ITS-station communications stack is consistent with the OSI communications stack and its levels, and
that each level above OSI Layer 2 must be paired; that is to say that the same technical solution must be
used (paired) by both the originating and destination system at each level of the stack.
For simplicity of representation, in terms of the OSI communications stack, the ‘Facilities’ layer relates to
the OSI ‘application’, ‘presentation’ and ‘session’ layers, and the “access” layer represents the combined
communication interfaces layers – i.e. the ‘data link’ layer (LLC, MAC) and the ‘physical’ layer
(IEEE 802.11; 3GPP Release 8, 3GPP Release 14, 3GPP Release 21; i/r ; I430/431; IEEE 802.3 etc.), The
‘Networking and transport’ layer maps to the ‘transport’ and ‘networking’ layer.
Figure 4 shows a high-level view of the communication between two ITS-stations
(Source: CSi UK)
Figure 4 — SI-2 – Implementation architecture
12
---------------------- Page: 14 ----------------------
SIST-TS CEN/TS 17875:2023
CEN/TS 17875:2022 (E)
An ITS-station may be situated in a vehicle, at the roadside, at a communications or service centre. The
purpose of the transaction is not material to the concept, and the concept is agnostic to the
communications technology so long as it can support the security requirements and required data rates.
However, some applications will have low latency requirements which limits their choice of
communications media.
The “Secure ITS Data Management and Access Interface” is a peer-to-peer communication between any
two ‘ITS-station’s, regardless of its use case. ISO 21217 provides the following illustration to show that
an ITS-station may be a vehicle, roadside, centre or personal device. See Figure 5.
(Source: ISO 21217:2020)
Figure 5 — SI-3 – Typical implementations of ITS-station units
The ‘Secure ITS Data Management and Access Interface’ is based on the ISO 21217 concept of
communications between “ITS-stations”.
For the ISIS the objective, using the ITS-station implementation architecture, can be illustrated as
Figure 6.
13
---------------------- Page: 15 ----------------------
SIST-TS CEN/TS 17875:2023
CEN/TS 17875:2022 (E)
Figure 6 — ISIS-3 – ISIS Architecture using ISO 21217 ITS-stations
And to abstract this away from any particular use case, we can illustrate as Figure 7.
Figure 7 — SI-4 – Generic Architecture using ITS-stations
But we cannot forget that, even in an emergency rescue situation, there are national and international
regulations that must be obeyed. And the regulations for the source instantiation may be different than
those for the destination instantiation. The host instantiation must operate within its regulatory
environment and the destination instantiation must operate within its regulatory environment.
Further, the application (eSafety ISIS in this use case), will probably be defined in International or
Regional Standards in order that both source and destination instantiations have common
understanding, common sequences, and common data concepts. These requirements are dealt with
outside of the ISO 21217 architecture, affecting the Host Application or the Destination Client Application.
See Figure 8.
14
---------------------- Page: 16 ----------------------
SIST-TS CEN/TS 17875:2023
CEN/TS 17875:2022 (E)
Figure 8 — SI-5 – Generic Architecture taking account of regulations and application standards
ISO 21217:2020 specifies what it calls a “bounded secured managed domain”, setting the overall basic
cybersecurity requirements (without demanding specific crypto-technologies, but giving
recommendations for ISO/TS 21177 and IEEE 1609.2), providing basic communications security across
the network, but leaving access details to the application level systems. However, in a paradigm where
the host system and application system may have different functionalities, different actors may have
different rights of access.
In this use-case (ISIS), for example, the fire brigade responders and police may need access to the
information concerning the cargo load of a crashed large goods vehicle, but that information must not be
available to other parties (It is commercially sensitive). If there is medical information available that
occupants of the vehicle have made available from wearable technology to the vehicle, using a Bluetooth
link, it should only be available to paramedic em
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.