1、 Reference number ISO/TR 17452:2007(E) ISO 2007TECHNICAL REPORT ISO/TR 17452 First edition 2007-04-15 Intelligent transport systems Using UML for defining and documenting ITS/TICS interfaces Systmes intelligents de transport Usage de UML pour dfinir et documenter les interfaces ITS/TICS ISO/TR 17452
2、:2007(E) PDF disclaimer This PDF file may contain embedded typefaces. In accordance with Adobes licensing policy, this file may be printed or viewed but shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In downloading th
3、is file, parties accept therein the responsibility of not infringing Adobes licensing policy. The ISO Central Secretariat accepts no liability in this area. Adobe is a trademark of Adobe Systems Incorporated. Details of the software products used to create this PDF file can be found in the General I
4、nfo relative to the file; the PDF-creation parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given belo
5、w. COPYRIGHT PROTECTED DOCUMENT ISO 2007 All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the addres
6、s below or ISOs member body in the country of the requester. ISO copyright office Case postale 56 CH-1211 Geneva 20 Tel. + 41 22 749 01 11 Fax + 41 22 749 09 47 E-mail copyrightiso.org Web www.iso.org Published in Switzerland ii ISO 2007 All rights reservedISO/TR 17452:2007(E) ISO 2007 All rights re
7、served iii Contents Page Foreword iv Introduction v 1 Scope . 1 2 Normative references . 1 3 Terms and definitions. 1 4 Abbreviated terms 3 5 Example of automatic vehicle and equipment identification . 3 6 Developing the data concepts in an application standard. 4 6.1 Use case 5 6.2 Classifiers 7 6.
8、3 Collaborations. 8 6.4 Parameters of the operations 9 6.5 Significant interfaces 12 6.6 Messages. 14 6.7 Information model for the interfaces 15 7 Registering the elements . 16 7.1 Example information model. 16 7.2 Data element definitions 19 7.3 Data frame definitions 21 7.4 Message definitions 22
9、 7.5 Interface dialogue definitions 23 Bibliography . 24 ISO/TR 17452:2007(E) iv ISO 2007 All rights reservedForeword ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies (ISO member bodies). The work of preparing International Standards is
10、normally carried out through ISO technical committees. Each member body interested in a subject for which a technical committee has been established has the right to be represented on that committee. International organizations, governmental and non-governmental, in liaison with ISO, also take part
11、in the work. ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization. International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2. The main task of technical committees is to pre
12、pare International Standards. Draft International Standards adopted by the technical committees are circulated to the member bodies for voting. Publication as an International Standard requires approval by at least 75 % of the member bodies casting a vote. In exceptional circumstances, when a techni
13、cal committee has collected data of a different kind from that which is normally published as an International Standard (“state of the art”, for example), it may decide by a simple majority vote of its participating members to publish a Technical Report. A Technical Report is entirely informative in
14、 nature and does not have to be reviewed until the data it provides are considered to be no longer valid or useful. Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. ISO shall not be held responsible for identifying any or all such
15、patent rights. ISO/TR 17452 was prepared by Technical Committee ISO/TC 204, Intelligent transport systems. ISO/TR 17452:2007(E) ISO 2007 All rights reserved v Introduction ISO 14817 specifies the formats and procedures used to define information exchanges within the ITS/TICS sector. Such information
16、 arises through the development of the architecture for a particular application standard and the subsequent specification of the detailed data concept instances that arise in association with the architectures interfaces. This Technical Report illustrates the steps involved in such development. In
17、the development of standards, it is often the case that working groups have a well-formed perception of the conceptual context within which their standard is to be applied. This is the case because many standards are the result of a refinement and consensus of requirements based on recent practice.
18、The formal process for the identification of the requirements is streamlined to capitalize on this available body of knowledge. For completeness, we begin with the capture of requirements. These requirements need be only those which directly affect the standard. The context of a real-world system th
19、at incorporates the standard would include a much wider range of requirements; however, we are focusing on that aspect of standards which produces data elements and other concept instances which will be registered in a data dictionary or registry. The methodology is derived from processes used in th
20、e development of software-intensive systems. TECHNICAL REPORT ISO/TR 17452:2007(E) ISO 2007 All rights reserved 1 Intelligent transport systems Using UML for defining and documenting ITS/TICS interfaces 1 Scope This Technical Report gives guidelines for using the unified modelling language (UML) for
21、 defining and documenting interfaces between intelligent transport systems (ITS) and transport information and control systems (TICS). It presents these guidelines in the context of a case study for the creation of an ITS/TICS data dictionary and submissions to the ITS/TICS data registry. In UML 6,
22、an interface is a collection of operations that used to specify a service of a class or component. The ITS/TICS data registry defined in ISO 14817 builds on this definition by mapping an operation to a message, and then it extends the definition of an interface to be a dialogue (i.e. a collection of
23、 messages within an implied protocol). This Technical Report conforms to these steps. 2 Normative references The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition of
24、the referenced document (including any amendments) applies. ISO 14817, Transport information and control systems Requirements for an ITS/TICS central Data Registry and ITS/TICS Data Dictionaries 3 Terms and definitions For the purposes of this document, the terms and definitions given in ISO 14817 a
25、nd the following apply. 3.1 automatic equipment identification AEI process of identifying equipment or entities that uses the surface transportation infrastructures by means of on-board equipment combined with the unambiguous data structure defined in ISO/TS 17261 NOTE “Equipment” indicates large eq
26、uipment that is carried in, or forms an integral part of, a trailer or trailer-mounted unit. 3.2 automatic vehicle identification AVI process of identifying vehicles using on-board equipment combined with the unambiguous data structure defined in ISO/TS 17261 ISO/TR 17452:2007(E) 2 ISO 2007 All righ
27、ts reserved3.3 electronic data interchange EDI passing of a data message, or series of messages, between computers and/or between different software systems NOTE 1 Within this context, an EDI message is normally compatible with the form specified in ISO 9897. NOTE 2 EDI is an instance of an electron
28、ic data transfer transaction. 3.4 goods provider party that provides goods to another party NOTE A goods provider can be a manufacturer, trader, agent or individual. 3.5 information data, documentation and other relevant knowledge organized to inform and describe 3.6 information manager function of
29、managing information in a system NOTE The role of information manager can be provided by one or many actors. It can be performed internally by one or more of the systems principal actors, or can be formed commercially or altruistically by one or more third parties. 3.7 intermodal transport movement
30、of goods in one or more loading unit or vehicle which uses successively several modes of transport without handling of the goods themselves when changing modes NOTE 1 Unlike multimodal transport (3.10), intermodal transport implies changing from one mode to another using the same form of loading uni
31、t. NOTE 2 See ISO/TS 17262 and ISO/TS 17263. 3.8 journey AVI/AEI physical movement of goods from the goods provider (3.4) to the receiver (3.11) 3.9 load that which is to be transported from the goods provider (3.4) to the receiver (3.11) NOTE A load comprises the consignment, packaging, pallets and
32、/or containers that are smaller than an ISO container. 3.10 multimodal transport carriage of goods by at least two different modes of transport cf. intermodal transport (3.7) NOTE Multimodal transport implies that either there is more than one modal shift, or that loads may be broken into partial lo
33、ads as part of a modal change. 3.11 receiver AVI/AEI one who receives goods as a result of a journey (3.8) from a goods provider (3.4) ISO/TR 17452:2007(E) ISO 2007 All rights reserved 3 3.12 returnables manager function that manages the supply, maintenance and returns cycle of returnable units (3.1
34、3) NOTE The returnables manager function may be performed by one or more of the systems principle actors or by an independent third party. 3.13 returnable unit unit used as part of a load (3.9), which is returned to the goods provider (3.4) or to a returnables manager (3.12) NOTE Pallets and trays a
35、re examples of a unit. 3.14 transponder tag electronic transmitter/responder which responds to the receipt of suitable modulated or unmodulated downlink signals and transmits predetermined information according to predefined protocols at a predetermined frequency NOTE The transmissions can be powere
36、d from energy obtained from the downlink or can be assisted by an on-board power supply. Forms the core, but not necessarily the only, function of an item of on-board equipment. Within the AVI/AEI context, it is fitted to the vehicle or equipment. Its prime function is to provide the identity of the
37、 item, but it can also contain additional information. For some special purposes, transponders can be installed in fixed positions and read by mobile equipment. 3.15 transport AVI/AEI vehicles/aircraft/ships used to move a consignment from the goods provider (3.4) to the receiver (3.11) or to move r
38、eturnable units (3.13) back through the system 3.16 transport means vehicles, trailers, vessels, aircraft or combination thereof which perform the journey (3.8) to deliver the consignment to the receiver (3.11) or to return returnable units (3.13), together with the driver/pilot/crew physically cond
39、ucting the journey 3.17 transport operator function that owns and/or manages the transport means (3.16) 4 Abbreviated terms AVI/AEI automatic vehicle and equipment identification RCU returnable container unit (see also 3.13) UML unified modelling language VMS variable message sign 5 Example of autom
40、atic vehicle and equipment identification To illustrate the steps in this tutorial, we use the example of AVI/AEI for intermodal goods transport as specified in ISO/TS 17261 3 and ISO/TS 17262 4. The overall application information architecture is shown in Figure 1. The key entities involved in the
41、architecture are defined in Clause 6. ISO/TR 17452:2007(E) 4 ISO 2007 All rights reservedThe context of Figure 1 is the information associated with the journey of goods from the goods provider to the end user. In this journey, the goods will form a load. The load can pass through several transport m
42、ode changes and other handling processes. In each instance, ISO/TS 17262 is applicable to an automated handling process. Figure 1 Schematic diagram of the application information architecture for the journey of goods from goods provider to receiver 6 Developing the data concepts in an application st
43、andard This tutorial employs UML 6 and illustrates how a process framed around UML (e.g. 7) can be employed to develop the behavioural descriptions of an application architecture 7, necessary to capture the interface data concepts. In the case of standards development, some of these concepts will be
44、 the focus of an application standard. The whole process can be broken into a sequence of steps (Figure 2), each of which has its own set of modelling artifices in UML. It is a straightforward matter to present an example in which the last step reveals a set of standard data elements. In practice th
45、e process is iterative, involving trial and error, and the steps are not always revisited in the same order. The application information architecture shown in Figure 1 serves to justify the development of a standard because it identifies the widespread applicability of the standard. However, it is n
46、ot sufficiently developed for defining the data concepts. This tutorial need only focus on a single goods-handling application function in order to illustrate the process of architecture development which culminates in data concept definition. The application is described in the first step of the pr
47、ocess of Figure 2, in which the requirements are defined by a use case. ISO/TR 17452:2007(E) ISO 2007 All rights reserved 5Figure 2 Steps in the development of the architecture items and data concepts 6.1 Use case As stated in 6, The use case construct is used to define the behaviour of a system or
48、other semantic entity without revealing the entitys internal structure. Each use case specifies a sequence of actions, including variants, that the entity can perform interacting with actors of the entity. ISO/TR 17452:2007(E) 6 ISO 2007 All rights reservedA use case captures the essence of a servic
49、e requirement. The user of the service (an actor) can be someone or it can be another system outside the target system. As stated in 6, An actor defines a coherent set of roles that users of an entity can play when interacting with the entity. An actor may be considered to play a separate role with regard to each use case with which it communicates. In our example (Figure 3), the purpose of the use case is to provide instructions to the driver of the transport means for a load (e.g. at the marshalling y