CEN/TS 17241:2019

SLOVENSKI STANDARD
01-junij-2019
Inteligentni transportni sistemi - Sistemi upravljanja prometa - Zahteve glede
stanja, napak in kakovosti
Intelligent transport systems - Traffic management systems - Status, fault and quality
requirements
Intelligente Verkehrssysteme - Verkehrsmanagementsysteme - Status-, Fehler- und
Qualitätsanforderungen
Ta slovenski standard je istoveten z: CEN/TS 17241:2019
ICS:
35.240.60 Uporabniške rešitve IT v IT applications in transport
prometu
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

CEN/TS 17241
TECHNICAL SPECIFICATION
SPÉCIFICATION TECHNIQUE
April 2019
TECHNISCHE SPEZIFIKATION
ICS 35.240.60
English Version
Intelligent transport systems - Traffic management
systems - Status, fault and quality requirements
Intelligente Verkehrssysteme -
Verkehrsmanagementsysteme - Status-, Fehler- und
Qualitätsanforderungen
This Technical Specification (CEN/TS) was approved by CEN on 14 January 2019 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, Former Yugoslav Republic of Macedonia, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania,
Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland,
Turkey 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
© 2019 CEN All rights of exploitation in any form and by any means reserved Ref. No. CEN/TS 17241:2019 E
worldwide for CEN national Members.

Contents Page
European foreword . 5
Introduction . 6
1 Scope . 8
2 Normative references . 8
3 Terms and definitions . 8
4 Symbols and abbreviations . 9
5 Quality and performance criteria . 10
5.1 Quality: fitness for purpose . 10
5.2 System quality . 11
5.2.1 Availability and uptime . 11
5.2.2 System compatibility and integration . 14
5.2.3 Configurability of systems . 14
5.2.4 Security . 15
5.2.5 Continuity of service and future proofing . 16
5.3 Device quality . 17
5.3.1 Physical robustness . 17
5.3.2 Failure modes . 17
5.3.3 Reliability and maintainability . 18
5.4 Functional quality . 19
5.4.1 Stated requirements and compliance . 19
5.4.2 Functional effectiveness . 19
5.4.3 Functional integration . 20
5.4.4 Usability . 21
5.5 Data quality . 21
5.5.1 Accuracy and related concepts . 21
5.5.2 Timeliness and granularity . 23
5.5.3 Spatio-temporal granularity . 23
5.5.4 System data . 24
5.6 Quality and performance management . 25
5.6.1 Lifecycle quality . 25
5.6.2 Quality evaluation . 27
5.6.3 Risk management . 28
6 System status and faults data model . 29
6.1 Overview . 29
6.2 General requirements . 29
6.3 Modelling principles . 30
6.3.1 Technical modelling principles . 30
6.3.2 Semantic modelling principles . 30
6.4 «D2Package» DevicePublication . 30
6.4.1 Overview . 30
6.4.2 Semantics . 31
6.5 «D2Package» StatusPublication . 32
6.5.1 Overview . 32
6.5.2 Semantics . 33
6.6 «D2Package» FaultPublication . 34
6.6.1 Overview . 34
6.6.2 Semantics . 36
6.7 «D2Package» Classes . 37
6.7.1 Overview . 37
6.7.2 Semantics . 39
6.8 «D2Package» DataTypes . 39
Annex A (normative) Status and fault data dictionary . 41
A.1 Disclaimer . 41
A.2 Overview . 41
A.3 Data dictionary of «D2Class» for “FaultAndStatus” . 42
A.3.1 “Classes” package . 42
A.3.1.1 Location of the “Classes” package . 42
A.3.1.2 “Classes” package classes . 43
A.3.1.3 “Classes” package association roles . 43
A.3.1.4 “Classes” package attributes . 44
A.3.2 “DevicePublication” package . 44
A.3.2.1 Location of “DevicePublication” package. 44
A.3.2.2 “DevicePublication” package classes . 45
A.3.2.3 “DevicePublication” package association roles . 45
A.3.2.4 “DevicePublication” package attributes . 46
A.3.3 “FaultPublication” package . 46
A.3.3.1 Location of “FaultPublication” package . 46
A.3.3.2 “FaultPublication” package classes . 47
A.3.3.3 “FaultPublication” package association roles . 47
A.3.3.4 “FaultPublication” package attributes . 48
A.3.4 “StatusPublication” package . 48
A.3.4.1 Location of the “StatusPublication” package . 48
A.3.4.2 “StatusPublication” package classes . 49
A.3.4.3 “StatusPublication” package association roles . 49
A.3.4.4 “StatusPublication” package attributes . 50
A.4 Data Dictionary of «D2Datatype» for “FaultAndStatus” . 50
A.4.1 General . 50
A.4.2 The «D2Datatype» “ObjectIdentifier” . 50
A.5 Data Dictionary of «D2Enumeration» for “FaultAndStatus” . 51
A.5.1 General . 51
A.5.2 The «D2Enumeration» “DeviceOrSystemTypeEnum” . 51
A.5.3 The «D2Enumeration» “FaultImpactOnDataEnum” . 51
A.5.4 The «D2Enumeration» “FaultSeverityEnum” . 52
A.5.5 The «D2Enumeration» “FaultTypeEnum” . 52
A.5.6 The «D2Enumeration» “FaultUrgencyEnum” . 53
A.5.7 The «D2Enumeration» “GeneralDeviceStatusEnum” . 53
A.5.8 The «D2Enumeration» “OperationalDeviceStateEnum” . 54
Annex B (normative) ASN.1 specifications . 56
B.1 Introduction . 56
B.1.1 General . 56
B.1.2 Automatic creation of ASN.1 code from xsd code . 56
B.1.3 ASN.1 module TmsStatusFault . 56
B.1.4 ASN.1 module PointLocation . 57
B.1.5 ASN.1 module DatexCommon . 57
B.1.6 ASN.1 module XSD . 57
B.1.7 ASN.1 module TmsMessageSet . 57
Annex C (normative) Management of electronic traffic regulations . 59
C.1 Justification . 59
C.2 Status and faults . 59
Annex D (normative) Electronic attachment . 60
Annex E (informative) Example use case . 61
E.1 Introduction . 61
E.2 Scenario “tunnel project” . 61
E.3 Use case “tunnel project” . 61
E.3.1 Challenge . 61
E.3.2 Response . 61
E.3.3 Mechanisms . 62
E.3.3.1 System Quality . 62
E.3.3.1.1 Availability and Uptime . 62
E.3.3.1.2 System Compatibility and Integration . 62
E.3.3.1.3 Configuration of system . 63
E.3.3.1.4 Security . 63
E.3.3.1.5 Continuity of service and future proofing . 63
E.3.3.2 Device Quality . 63
E.3.3.2.1 Physical Robustness. 63
E.3.3.2.2 Failure Modes . 64
E.3.3.2.3 Reliability and Maintainability . 64
Bibliography . 65

European foreword
This document (CEN/TS 17241:2019) has been prepared by Technical Committee CEN/TC 278
“Intelligent transport systems”, 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.
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, Former Yugoslav Republic of Macedonia,
France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta,
Netherlands, Norway, Poland, Portugal, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland,
Turkey and the United Kingdom.
Introduction
General deployment of Intelligent Transport Systems (ITS) in the field of road transport and for
interfaces with other modes of transport is demanded by Directive 2010/40/EU [3] of the European
Parliament. ITS means “applying information technology and communications technology for improving
traffic, especially road traffic”.
Urban Intelligent Transport Systems (U-ITS) is a term indicating the provisioning of ITS services
applying ITS technologies in an urban context. Development of standards dedicated to U-ITS is
supported by the European Commission's mandate M/546 [2] with technical details identified in the
final report [1] of project team PT1701 funded under M/456. U-ITS standards will complement those
for cooperative ITS (C-ITS) developed under the European Commission's mandate M/453, see [4]. Thus
the basic ITS technologies applied for U-ITS are the same as those applied for C-ITS.
Provisioning of ITS services typically may require communications between ITS station units (ITS-SU)
[20]. Diverging requirements for communications and limitations of capabilities of available
communication channels led to the concept of Hybrid Communications providing multiple
communication protocol stacks with different access technologies for localized communications and
networked communications together with the capability of handover, specified in a series of standards,
ISO 21217 [20], ISO 21218 [21], EN ISO 17423 [14], ISO 24102-6 [24], ISO 21215 [19],
ISO 17515-3 [16], ISO 21210 [18], ISO 29281-1, and others.
A major characteristics of C-ITS is the sharing of data between ITS applications in the same ITS-SU and
in different ITS-SUs. A major service domain of C-ITS is the domain of road safety and traffic efficiency,
with a certain focus on wireless communications between ITS-SUs installed in vehicles, also referred to
as Vehicle ITS-SU (V-ITS-SU), and wireless communications between V-ITS-SUs and ITS-SUs installed at
the roadside, also referred to as Roadside ITS-SU (R-ITS-SU).
Major differences between U-ITS and C-ITS are the data and procedures necessary for the provisioning
of dedicated urban ITS services, although data and procedures developed for C-ITS might also be
beneficially applied in U-ITS.
Whilst C-ITS focused on the road safety domain, U-ITS deals with the ITS service domains
Multimodal Information Systems;
Traffic Management;
Urban Logistics;
see [1].
A major goal to be achieved with U-ITS standards is to assist urban administration to implement U-ITS,
and by this removing barriers for implementing U-ITS [1]:
1) Awareness of what is available;
2) Location referencing;
3) Vendor lock-in;
4) Standards for “new modes” and “new measures”;
5) Data exchange / data management;
6) Immaturity of some concepts.
A precise definition of the borderline between U-ITS and ITS for other target domains, e.g. ITS on
highways, is impossible. However, this document aims on identifying and specifying ITS issues that are
relevant for urban administrations. It is important to understand that ITS issues developed for urban
areas also may be applicable outside of urban areas.
Development of standards for U-ITS has to consider automated and autonomous vehicles [1].
This document was developed by project team PT1704 funded by the European Commission under
grant agreement SA/CEN/GROW/EFTA/546/2016-08 'Urban ITS - Traffic management systems'
(M/546 [2]). The scope of this document results from the High Level Recommendation “1701-
HLRd Traffic Management System status, fault and quality standards” identified in Bibliographical
Entry [1]. This document is about quality and performance criteria:
— applied for the operation of traffic management systems,
— considering the effective integration of field and centre
— devices and
— services,
— and approaches to evaluate them.
PT1704 acknowledges the help of
OSS Nokalva, Inc.
300 Atrium Drive, Suite 402
Somerset, New Jersey 08873
USA
to develop the ASN.1 equivalent code from the XSD code produced by the UML design tool (Enterprise
Architect [39]). OSS voluntarily processed the XSD files provided by PT1704 with their XSD- > ASN.1
Translator tool [38].
Clause 5 is arranged as a text book, introducing and explaining quality and performance criteria, and
approaches to their evaluation, for the operation of traffic management systems, including factors
affecting the effective integration of field and centre systems and services. Where appropriate, it refers
to the data model specified in Clause 6. Normative requirements are avoided in order not to impose
requirements on urban administrations on how to perform their work.
Clause 6 specifies a data model for system status and faults of components of traffic management
systems using UML and being based on DATEX II. The design is flexible, i.e. supporting communications
between central stations, i.e. the original usage of DATEX II, but also communications between a field
device and a central station. Further on it introduces the concept of “catalogues” allowing vendors and
urban administrators defining their own data sets.
The informative Annex E illustrates the general findings of Clause 5 using a use-case “tunnel project”. To
a large extent there is a one-to-one mapping of subclauses from Clause 5 with subclauses from Annex E.
The normative Annex A specifies a status and fault dictionary.
The normative Annex B provides an ASN.1 module for the data specified in Annex A.
The normative Annex C provides a contribution to the CEN work item on management of electronic
traffic rules (METR).
The normative Annex D provides information about the existence and the content of an electronic
attachment to this document.
1 Scope
This document:
— illustrates quality and performance criteria, and approaches to their evaluation, for the operation of
traffic management systems, including factors affecting the effective integration of field and centre
systems and services, and
— specifies a data model for system status and faults of components of traffic management systems.
This document provides supporting information in a use case for the use of the quality and performance
criteria, considering design, procurement, and performance management.
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.
EN 16157-1:2018, Intelligent transport systems — DATEX II data exchange specifications for traffic
management and information — Part 1: Context and framework
EN 16157-2:2019, Intelligent transport systems — DATEX II data exchange specifications for traffic
management and information — Part 2: Location referencing
EN ISO 17419 , Intelligent transport systems — Cooperative systems — Globally unique identification
(ISO 17419)
ISO 29281-1, Intelligent transport systems -- Localized communications -- Part 1: Fast networking &
transport layer protocol (FNTP)
ISO/IEC 8824-1, Information technology — Abstract Syntax Notation One (ASN.1): Specification of basic
notation — Part 1
ISO/IEC 8825-2, Information technology — ASN.1 encoding rules: Specification of Packed Encoding Rules
(PER) — Part 2
ISO/IEC 8825-5, Information technology — ASN.1 encoding rules: Mapping W3C XML schema definitions
into ASN.1 — Part 5
ISO/IEC 9834-1, Information technology — Procedures for the operation of object identifier registration
authorities: General procedures and top arcs of the international object identifier tree — Part 1
3 Terms and definitions
No terms and definitions are listed in this document.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
• IEC Electropedia: available at http://www.electropedia.org/
• ISO Online browsing platform: available at http://www.iso.org/obp

The next edition of ISO 17419 will be split into a two-part document.
4 Symbols and abbreviations
CCTV closed circuit television
DATEX II multi-part standard, maintained by the CEN Technical Committee 278,
CEN/TC278, specifying the information model for road traffic and travel
information in Europe
DIASER dialogue standard pour les equipements de régulation
NOTE 1   AFNOR standard defining traffic data collection in an urban or peri-urban
environment with traffic control via traffic signals. It applies to exchange between a
management centre and equipment or actors out on the field (traffic signal equipment
used for traffic control purposes, data exchange between a traffic controller and an
external system); see [31].
ETR electronic traffic regulations
HMI human-machine interface
IT information technology
ITS intelligent transport system
METR management of electronic traffic regulations
MOR minimum operating requirements
NTCIP national transportation communications for ITS protocol
OCIT open communication interface for road traffic control systems
PER (ASN.1) packed encoding rules
PRINCE2 projects in controlled environments
NOTE 2   Standard-like specification from AXELOS.
PTZ pan, tilt, zoom
QMA quality management authority
SLA service level agreement
UA urban administrator
U-ITS urban ITS
UML unified modelling language
UPER ASN.1 BASIC-PER UNALIGNED
UTMC urban traffic management control, i.e. initiative in the UK for the development of
an approach to ITS in urban areas
VMS variable message sign
5 Quality and performance criteria
5.1 Quality: fitness for purpose
There is no universally accepted definition of “quality”. In EN ISO 9000:2015, 3.6.2 [6], it is defined as
the “degree to which a set of inherent characteristics (…) fulfils requirements”, but while this helps to
frame the generic standards for quality management, it is of little practical use in specific contexts.
“Performance”, similarly, may refer generally to the actual behaviour of a system in practice, or more
directly to the system's achievement of the desired “quality”.
Definitions in the business context vary widely, but may be broadly categorized into a number of
perspectives, including:
— Those that focus on the fulfilment of a functional goal (effectiveness).
— Those that focus on the fulfilment of a contractual goal or policy requirements (compliance).
— Those that focus on the fulfilment of stakeholder expectations (satisfaction).
— Those that focus on the improvement of one or more of the above (excellence).
There are several factors that contribute to the quality of an operational system in practice. In
particular, these include:
— Design quality for individual system elements (devices, software packages, etc).
— System management quality (deployment, integration/configuration, maintenance, etc).
— System operation quality (staffing, processes, etc).
In the specific context of traffic management systems, there are a number of complicating factors
although they are not unique to this context.
— The “traffic management system” includes not just a set of interacting ITS station units, but also the
people that provide and operate them.
— Both ITS station units and people are likely to be spread across multiple organizations.
— “Customers” do not generally pay to use the service – the quality incentive therefore devolves on
policymakers rather than market transactions, which is often less transparent and more volatile.
— The traffic management system is not independent of other civic systems – for instance those
related to the management of the economy, the environment, education or social care.
— Many elements of the system – expectation, technology, external factors – are changing faster than
they can reasonably be addressed.
To achieve all this, approaches to quality management generally involve many aspects of a business
operation, including organization, process, communication, documentation, and so on. The general aim
of a quality management system is to foster operational structures and behaviour that tends to increase
quality, as it is defined and measured within the organization, and simultaneously reduce or remove
structures and behaviour that tends to decrease quality.
These complexities impose a number of specific, preliminary, and overarching requirements on
owners/operators of traffic management systems in line with the approach of EN ISO 9000 [6].
NOTE Many organizations find it helpful to appoint a quality management authority (QMA), responsible for
designing and overseeing the operation of the quality management system. The exact form and role of such a QMA
will reflect the nature and context of the organization. In the context of C-ITS, a model on roles and responsibilities
was identified and standardized in EN ISO 17427-1 [15]. This might, at least partly, also apply for U-ITS.
The performance goals of a system (i.e. its target quality) should be clearly and unambiguously stated as
far as practical, taking into account the relevant provisions of Clause 5 of this document.
Many systems are integrated from multiple components. The stated output goals for any specific system
component should not exceed a performance level that can be effectively used by at least one current or
anticipated future system function. For example, requiring a detector to providing vehicle location data
to 1 m accuracy every 100 ms is inappropriate, if the only user of this data are a flow monitoring system
that reports total vehicle flow in 5 min intervals. It may be reasonable, though, if the authority expects
shortly to implement a collision warning system. It may also be acceptable if the marginal cost, relative
to a much lower-performance unit, is small.
Where externalities - typically, either poor legislation or regulation or poor senior management
decisions - impose a specific challenge that will be difficult or impossible to meet, the issue should be
raised through the relevant political or legal channels as a matter of urgency. If this is not done, there is
a risk that either:
a) the roads authority could be unfairly penalized, or
b) a legal instrument could be rejected as unreasonable by the courts.
The following subclauses address the quality of traffic management systems under the following
headings:
— 5.2 covers the technical quality of traffic management systems, including intelligent transport
systems, as a whole.
— 5.3 covers the quality of specific devices that are combined into systems.
— 5.4 covers the functional quality of systems: how well they do what they do.
— 5.5 covers the quality of the data that is created, held and processed within systems.
— 5.6 covers the management of system quality and operational aspects, at different stages of system
life cycle.
5.2 System quality
5.2.1 Availability and uptime
5.2.1.1 General
One of the most basic quality factors, but often one of the most difficult to describe unambiguously, is
“system availability”: loosely, how much of the time the system is working properly. A simple
percentage is often quoted, e.g. “99% availability”, but this is rarely adequate for the reasons discussed
below.
— What is meant by “how much of the time”.
— What is meant by “the system” or by “the whole system”.
— What is meant by “working properly”.
In order to limit scope for misunderstanding, therefore, and to maximize the intentions of the authority
being met, it is essential to attempt to document how these should be understood.
5.2.1.2 Time
The nature of the system may be such that its operation is not equally important throughout the day,
and may vary from day to day. This can become important for a number of factors, including when to
schedule preventive maintenance and what response time is required in the event of a system failure. It
may be more acceptable (or less) to suffer many short outages than a single long outage. Finally, very
short outages (say, below one second) may or may not be tolerable at system level.
The system specification should incorporate a statement that describes as fully as possible the specific
requirements on system uptime. This should include:
— The period or periods over which availability will be measured;
— Minimum and maximum acceptable outage lengths within each measured period;
— Maximum total outage within each measured period.
5.2.1.3 System
An authority will have requirements for the operational availability of the whole of its traffic
management system, as it is deployed and operated. However, if this system contains many different
components – possibly from multiple suppliers – it may not be possible to connect and enforce these in
a contractual context. In particular, a traffic management system is likely to include hardware such as
computers, signal heads, variable message sign (VMS) displays, etc., services such as communications,
power supply, etc., and application software such as signal strategies, user interface, etc. This
represents an integration challenge. Figure 1 shows a typical limited and artificial example, which
indicates a number of procured components linked together into an overall traffic management system:
— The input on the left hand side may include:
— keyboard and mouse control from the operator;
— data from road users (vehicles, pedestrians, etc.) and their systems, either directly
(e.g. generated by an in-car system) or indirectly (e.g. from a number plate read by a camera);
— and direct import of external data, e.g. weather systems or police systems.
— Applications of various kinds process the data, and share some of their outputs with each other
applications. These elements represent products that are procured, implemented and operated.
— The output on the right hand side may include
— system displays to the operator;
— signal aspects, signage, barriers etc. on the road;
— and directly published data, for example via authority websites, to public transport companies,
etc.
Figure 1 — Example of a system and its components
Failure of one component may or may not affect failure of other components. Some failures will affect
the whole system; others may be very localized, e.g. to one junction or to one user workstation.
Not all component failures result in system failure. To take a trivial example, it is clearly unreasonable
to declare a system non-operational because an operator screen has a missing pixel. It is important,
therefore, to present clearly what counts as a failure; especially for contractual purposes.
Nevertheless, it is important to address the actual operational requirements. To address this, an
authority should document the availability of the system as a whole, with reference to the intended
output functionality. The purpose of this is to assist the system manager in ensuring continued good
operation.
From this, using appropriate analytical tools, such as fault tree analysis, the authority should determine
acceptable levels of availability for the separate system components which are the subject of
procurement and maintenance contracts. These availabilities should be explicitly referenced in the
relevant contracts – noting that in some cases, there may be little or no scope for negotiation; especially
with regard to already-acquired systems.
The relationship between system availability and component availability is complex, and the availability
target will influence the optimal system architecture. In particular, component redundancy may be a
way of boosting the availability of the overall system with relatively inexpensive and less-reliable
components. Expert architecture support may well be helpful in this process, either as part of a system
integrator contract, or independently of suppliers.
5.2.1.4 Working properly
For the system, “working properly” strictly means “meeting all the explicit and implicit output
requirements” – namely, to the right hand side of Figure 1. While correct output generally requires
correct operation throughout, this is not necessarily the case; for example, if a component manages
relatively static data such as road layout, it may not matter if the input to this component suffers minor
interruptions.
Moreover, “working properly” ought not to be treated as a binary distinction. For instance, if a traffic
signal control algorithm is faulty, and leads to excessive queuing, clearly the product is not fulfilling its
role, and there are grounds for redress against the supplier. However, if the signals are still correctly
showing red and green phases, there may be relatively little concern other than a longer-than-expected
wait. Similarly, if a car park guidance system shows space information that is 15 min old, it is likely to
be only mildly frustrating.
There is therefore a distinction to be made between issues that should be rectified because they cause
significant operational issues such as safety concerns, and those which are more a question of
optimization. Both are important and shall be addressed, but the obligations to be placed on suppliers
will be different in each case.
A common approach is to categorize issues into a hierarchy of importance and urgency, using terms
such as “m
...