C-ITS: Minimum Requirements and behaviour for Core Systems.
This page : ‘C-ITS Minimum system requirements and behaviour for core systems’ : critical Minimum system requirements and behaviour for core systems, consides issues that C-ITS service provision may face or introduce; to consider strategies for how to identify, control, limit or mitigate such issues.
Inspiration for the technical content Identification and consideration of the ‘Minimum system requirements and behaviour for core systems’ has been largely obtained from various documents generated and publicised by US DoT RITA, especially ’ ‘Core System’ Requirements Specification (SyRS)’ and we acknowledge the source and thank US DoT for permission to reuse.
Conceptual input from the EC project CVIS is also acknowledged.
Contribution from the Australian National Transport Commission, Cooperative Intelligent Transport Systems Policy Paper (A Report prepared by: National Transport Commission ISBN: 978-1-921604-47-8) is also acknowledged
This sub- page should be read in conjunction with the sub-pages on this site for “ Roles and responsibilities based on architecture(s)”,” Framework overview “ and “ Concept of operations (CONOPS) for ‘Core’ systems”
Stakeholders
The term “stakeholder” may be somewhat overused but generally refers to any individual or organization that is affected by the activities of a business process or a system being developed. They may have a direct or indirect interest in the activity and their level of participation may vary. The term here includes public agencies, private organizations or the traveling public (end service recipients) with a vested interest, or a "stake" in one or more aspect of the connected vehicle/highway system environment (3.17) and the ‘Core System’.
‘Core System’ stakeholders span the breadth of the transportation environment including:
-
Transportation service recipients, e.g., private vehicle drivers, public safety vehicle operators (3.34), commercial vehicle operators, passengers, cyclists and pedestrians
-
Transportation operators, e.g. traffic managers, transit managers, fleet managers, toll operators, road maintenance and construction
-
Public safety organizations, e.g. incident and emergency management, including fire, police and medical support
-
Information service providers, e.g. data and information providers for transportation- related data, including traffic, weather and convenience applications
-
Application service (3.4) providers
-
Environmental managers, including emissions and air quality monitors
-
Original equipment vehicle manufacturers (OEMs)
-
In-vehicle device manufacturers
-
Communications providers, including cellular network operators
-
Jurisdiction regulatory and research agencies
-
‘Core System’ owners.
To obtain a summary of the roles and relationships associated with C-ITS and its core systems see our’ roles and Responsibilities’ page or ISO 17427-1.
ISO 17427-1 ‘Intelligent transport systems — Co-operative systems — Roles and responsibilities based on architecture(s)’ envisions the following:
-
Applications that provide functionality to realize safety, mobility and environmental benefits,
-
Communications that facilitate data exchange,
-
Core Systems, which provide the functionality needed to enable data exchange between and among mobile and fixed transportation service recipients, and
-
Support Systems, including security credentials certificate and registration authorities, that allow devices and systems to establish trust relationships.
The following diagams show core systems as envisaged by US DoT, and Core systems as envisaged by IBM.
The main mission of any ‘Core System’ is to enable safety, mobility and communications-based applications for both mobile and non-mobile service recipients.
It must always be in mind that is not the principle role of the ’core system’ to provide end user application services. Such services may be provided by the same computing and communications equipment, but are, and need to be, kept separate from the ‘core system’.
A ‘Core System’ includes those enabling technologies and services that will in turn provide the foundation for applications. The ‘Core System’ works in conjunction with ‘External Support Systems’ (ESS) like a ‘Certificate Authority’ (CA) for wireless communications security. The system boundary for the ‘Core System’ is not defined in terms of devices or agencies or vendors, but by the open, standardized interface specifications that govern the behaviour of all interactions between ‘Core System’ service recipients.
What the 'core system' does
The ‘Core System’ supports a distributed, diverse set of applications. These applications use both wireless and wireline communications to provide:
-
Wireless communications with and between mobile elements including vehicles (of all types), pedestrians, cyclists, and other transportation service recipients
-
Wireless communications between mobile elements and field infrastructure
-
Wireless and wireline communications between mobile elements, field infrastructure, and back office/centres
While this may provide support and security management for ITS specific wireless communications, such as 5.9GHz, it may also provide gateway and/or SAP access/management to public wireless communications such as 4G/LTE/3G/2G (E_UTRAN/UMTS/GSM) or mobile wireless broadband, WiFi and even satellite telecommunications.
The operational environment in which the ‘Core System’ exists may vary from a single jurisdiction-wide monolithic system to a heterogeneous community of systems run by multiple agencies at different levels of complexity and various locations. The potential number of scenarios involving transport-related system service recipients is unlimited but all will involve some sort of wireless communication. Applications may be deployed in complex configurations supporting a major metropolitan area or a minimal configuration to support a set of isolated rural road warning systems.
As ‘Core Systems’ are deployed, some may include just the essential functions to support a particular local area and rely on an interface to another ‘Core System’ to provide additional services. For instance, one ‘Core System’ could include the necessary hardware and software to manage a subset of the subsystems for their local area and rely on a connection to another ‘Core Systems’ subsystems for additional services.
A ‘Core System’ does not necessarily require a control centre with large video screens or employ a large number of operators. A ‘Core System’ can function in an office or data centre environment as long as there is access to a network that enables communications between system service recipients and the ‘Core System’. A ‘Core System’ also does not necessarily imply a system provided by a single central mainframe computer, and ‘core system’ functionality may indeed be provided by a number of networked computers. However the core ‘system’ is a single cohesive ‘system’ and there needs to be a clear line of management and control.
See our CONOPS page or ISO TR 17427-3 - Cooperative ITS – Concept of operations (CONOPS) for ‘Core’ systems for more detailed discussion and detail of these aspects.
A ‘Core System’ to support C-ITS service provision may be designed and implemented in some cases as a nationally deployed and managed system but in other cases will likely be deployed locally and regionally and it must be able to grow organically to support the changing needs of its user base. Deployments may be managed regionally but will need to follow International standards to ensure that the essential capabilities are compatible no matter where the deployments are established.
‘Core System’ supports the connected vehicle/highway system environment by being responsible for providing the services needed to facilitate the data exchanges. The contents of the data exchange are determined by applications unless the data exchange is used as part of the facilitation process between the user and the ‘Core System’.
The ‘Core System’ needs to have an intimate relationship with the ‘Certification Authority’, and there may be logic that the two aspects have common management to ensure consistency.
The ‘Core System’ also provides networking services to facilitate communications, though it does not comprise the communications network.
Core-to-Core Subsystem(s)
In most, but not all, paradigms, the system will need to operate/co-operate with adjacent and/or parallel ‘Core Systems’. See the CONOPS sub-page of this site and ISO TR 17427-3 - Concept of operations (CONOPS) for ‘Core’ systems.
This implies a requirement for a ‘Core2Core subsystem’. The Core2Core subsystem needs to interface with other ‘Core Systems’, declaring its jurisdictional scope, offered services, and services it desires from other ‘Core Systems’. The Core2Core subsystem will then need to maintain a knowledge base of data and services available among other ‘Core Systems’. In this way the ‘Core System’ can act as a system user to another ‘Core System’, providing proxy services that it does not offer but another ‘Core System’ does.
Additionally, the Core2Core subsystem is responsible for compatibility between ‘Core Systems’, ensuring that one ‘Core System’ does not encroach on the scope of another ‘Core System’, and similarly accepting error messages from mobile service recipients that might indicate a cross-jurisdictional compatibility or scope coverage issue. Interfaces between ‘Core Systems’ will be formalized in interface specifications. Conflicts and discrepancies between ‘Core Systems’ will have to be resolved by agreements between the organizations responsible for the respective ‘Core Systems’.
Data Distribution Subsystem
The ‘Data Distribution subsystem’ needs to maintain a directory of system service recipients that want data and facilitates the delivery of that data to those service recipients. It needs to supports multiple distribution mechanisms, including:
-
Source-to-Points: The data provider communicates data directly to data consumers. In this case no data is sent to the ‘Core System’, however the ‘Core System’ is involved to check system user permissions and to provide addressing services through those subsystems
-
Publish-Subscribe: The data provider communicates data to the ‘Data Distribution subsystem’, which forwards it to all service recipients that are subscribed to receive the data.
-
The ‘Data Distribution subsystem’ allows data consumers to specify (and change the specification of) data they wish to receive using criteria including:
-
Data type
-
Data quality characteristics
-
Data format requirements
-
Geographic area
-
Sampling rate
-
Minimum and maximum frequency of data forwarding
Registry
The ‘Data Distribution subsystem’ needs to maintain a registry of which data consumers get what data according to the criteria defined above. Data distribution ‘Publish-Subscribe’ should not store or buffer data beyond that which is necessary to complete publish-subscribe actions.
The degree to which data distribution buffering accommodates connectivity failures will be a function of the design of the ‘Core System’ deployment. Some ‘Core Systems’ may be designed to offer “temporary storage”.
The ‘Data Distribution subsystem’ will need to repackage data it receives from data providers, stripping away the source header information, and anonymising the data, while maintaining the message payload. It then sends the repackaged payload data to subscribers of that data.
Acting within the limits of the Privacy regulations of the jurisdiction, the ‘Data Distribution subsystem’ will need to securely retain a temporary archive linking the data to the data provider, in case misbehaviour is reported. The duration of such data retention should be minimised as far as is practicable and subject to stringent access controls.
The ‘Data Distribution subsystem’ will also need to maintain source-to-points information. With this option, the data consumer will connect directly to the data provider with the address supplied by the ‘Data Distribution subsystem’. When connected, the data provider sends the data directly to each consumer, bypassing the ‘Core System’. This must be achieved within privacy regulations.
The ‘Data Distribution subsystem’ does not share or exchange data with other ‘Core Systems’. System service recipients that require data from multiple ‘Core Systems’ need to subscribe to each ‘Core system’.
Misbehaviour Management Subsystem
The ‘Misbehaviour Management subsystem’ needs to analyse messages sent to the ‘Core System’ to identify service recipients operating outside of their assigned permissions. It will need to work with the ‘User Permissions subsystem’ to identify suspicious requests and to maintain a record of specifically identifiable service recipients that:
-
Provide false or misleading data
-
Operate in such a fashion as to impede other service recipients
-
Operate outside of their authorized scope
Because most end service recipients will rarely interface with the ‘Core System’, the ‘Misbehaviour Management subsystem’ will also need to accept reports of misbehaving service recipients from other service recipients: centre, mobile, and field service recipients may send misbehaviour reports that reference credentials attached to messages and note the type of misbehaviour in question. (Of course they will not usually be able to identify the source because it will have been anonymised).
A ‘Misbehaviour Management subsystem’ needs to record such reports and according to a set of ‘Core System’ personnel-controlled rules, which will determine when to revoke credentials from such reported misbehaving service recipients. For anonymous service recipients, revocation is more complex and may result instead in a lack of credential renewal. Large numbers of failed renewals could have a significant effect on operations; system requirements and design activities will need to ensure that renewal failures do not adversely affect system performance or user experience.
Network sevices subsystem
Within the core system, a ‘Network Services subsystem’ provides information to system service recipients and provides ‘Core System’ services that enable communication between those service recipients and services. The ‘Network Services subsystem’ will provide the information necessary for service recipients to communicate with other service recipients who have given permission for such communication. The ‘Network Services subsystem’ will also need to provide the information necessary to enable service recipients to communicate with a group of service recipients by maintaining information regarding available communications methods, addresses, and performance characteristics for geo-cast communications.
A ‘Network Services subsystem’ will also provide management for communications layer resources. It will enable decisions about which communications medium to use when more than one is available. This includes identifying available communications methods current performance characteristics and applicable user permission levels. Permission requirements will be coordinated with the ‘User Permissions subsystem’.
System service monitor subsystem
A ‘System service monitor subsystem’ exists to monitor the status of ‘Core System’ services, interfaces, and communications networks connected to the ‘Core System’. It will have to inform system service recipients of the availability and status of its services.
The ‘System service monitor subsystem’ also needs to monitor the integrity of internal ‘Core System’ components and supporting software, and mitigate against vulnerabilities. This will include periodic verification of the authenticity of ‘Core System’ service software and supporting software. This will also include monitoring for vulnerabilities including but not limited to virus protection, network port monitoring, and monitoring for patches to third party components. Should a vulnerability be detected or a component of the ‘Core System’ be found to have lost integrity, the ‘System service monitor subsystem’ will need to take steps to mitigate against damage and performance degradation.
A ‘System service monitor subsystem ‘ will have to ensure the physical security of ‘Core System’ services by monitoring the environmental conditions within which ‘Core System’ components operate (e.g. temperature and humidity) as well as the condition of its power system. The ‘System service monitor subsystem’ will need to take steps to mitigate against system failures in the event that environmental conditions exceed operating thresholds. Actions could include the activation of environmental or backup power systems and/or the modification of ‘Core System’ service operations, as well as ‘core system’ personnel (‘Core System’ staff) notification.
A ‘System service monitor subsystem’ also needs to monitor the performance of all services and interfaces and makes performance metrics available to ‘core system’ personnel (‘Core System’ staff).
A system service monitor subsystem must also monitor the status of ‘Core System’ services, interfaces, and communications networks connected to the ‘Core System’. It needs to inform system service recipients of the availability and status of its services.
A system service monitor also needs to monitor the integrity of internal ‘Core System’ components and supporting software, and mitigates against vulnerabilities. This will include periodic verification of the authenticity of core service software and supporting software. It also includes monitoring for vulnerabilities including but not limited to virus protection, network port monitoring, and monitoring for patches to third party components. Should a vulnerability be detected or a component of the ‘Core System’ found to have lost integrity, system service monitor takes steps to mitigate against damage and performance degradation.
Time Synchonisation Subsystem
A ‘Time Synchronization subsystem’ provides a common time base available to all system service recipients and makes this time available to all ‘Core System’ services, which will use this time base whenever a time reference is required.
User Pemissions Subsystem
A ‘User Permissions subsystem’ needs to provide tools allowing system service recipients to verify whether a given user, identified by digital certificate-based credentials, is authorized to request or perform the action requested in the message payload. It needs to maintain the status of service recipients, whether they have a specific account, their allowed behaviours with defined permissions (publish, subscribe, actions allowed to request, and administration etc.), or if they belong to an anonymous group.
The ‘User Permissions subsystem’ needs to provide the tools for ‘core system’ personnel to: create new service recipients and groups, modify existing service recipients and groups, and modify permissions associated with service recipients and groups.
User Trust Management Subsystem
A ‘User Trust Management subsystem’ is required in order to manage access rules and credentials in an appropriate and internationally agreed form for all system service recipients and ‘Core System’ components that require and are entitled to them. A ‘User Trust Management subsystem’ will create and distribute cryptographic keys to qualifying system service recipients. The ‘User Trust Management subsystem’ will need to work with the ‘User Permissions subsystem’ to determine whether a given user applying for credentials or keys is entitled to them.
A ‘User Trust Management subsystem’ is also needed to manage the revocation of credentials and the distribution of ‘Certificate Revocation Lists’ (CRLs) of disallowed credentials to interested system service recipients.
The provision, distribution, and management of appropriate digital certificates (both identity and anonymous certificates) that are primarily used by mobile and field service recipients using wireless communications media (e.g. 5.9 GHz) will be managed by the ‘User Trust Management subsystem’ who will have to forward requests for certificate revocation for misbehaving system service recipients from ‘Misbehaviour Management’ according to the regime it creates.
Some wireless communications media will be handled by an ‘External Support System’ (ESS). The user trust management subsystem will maintain a relationship with this ESS, and provide information about how to contact this ESS to interested system service recipients.
The ‘User Trust Management’ subsystem will forward requests for certificate revocation for misbehaving system service recipients from the misbehaviour management subsystem to this ESS.
What are the key minimum system requirements and behaviour for core systems issues?
Core System Requirements
This tables below provides the high-level requirements for the ‘Core System’,i.e. “What the systems shall do”. They are organized by the types of requirements and are related to the requirements identified in the ConOps (ISO TR 17427-3).
Core Systems - Other requirements
Physical Security
IAccess control has to be provided in crucial areas such as the computer rooms, entrance rooms, electrical and mechanical areas. (Suggestion: as specified in the ANSI TIA-942 Telecommunications Infrastructure Standard for Data Centres.)
Environmental features
The equipment hosting the ‘Core System’ needs to specify the conditions under which it operates. ANSI TIA-942 Telecommunications Infrastructure Standard for Data Centres) is recommended.
Back-up Power
The facility hosting the ‘Core System’ nodes needs to include supplemental power (Suggested: generator or uninterruptible power supply (UPS)) as specified in IEEE Standard 446 Recommended Practice for Emergency and Standby Power System for Industrial and Commercial Applications).The Core System's equipment needs to be installed in electrically grounded network equipment racks. (Suggested: as specified in the ANSI TIA-942 Telecommunications Infrastructure Standard for Data Centres)
Internal Interfaces
The table Internal subsystem to subsystem interfaces shows the US DoT view of internal interfaces between subsystems within a typical ‘Core System’. The column on the left represents the subsystems that will be sending data to the subsystems represented by the columns to the right.
Internal subsystem to subsystem interfaces
5.9 GHz Security credential requirements
Only some C-ITS communications will use 5.9GHz dedicated wireless communications, but some of these uses will be critical C-ITS systems envisaged and these will need security credentials. This will need to be managed by the ‘Certificate Authority’. See ISO 21177.