BS PD CLC TR 50501-1-2007 Railway applications — Rolling stock — Intercommunication nbetween vehicles and train wayside — Part 1 Data dictionary and rules for functional .pdf

《BS PD CLC TR 50501-1-2007 Railway applications — Rolling stock — Intercommunication nbetween vehicles and train wayside — Part 1 Data dictionary and rules for functional .pdf》由会员分享，可在线阅读，更多相关《BS PD CLC TR 50501-1-2007 Railway applications — Rolling stock — Intercommunication nbetween vehicles and train wayside — Part 1 Data dictionary and rules for functional .pdf（50页珍藏版）》请在麦多课文档分享上搜索。

1、PUBLISHED DOCUMENT PD CLC/TR 50501-1:2007 Railway applications Rolling stock Intercommunication between vehicles and train/wayside Part 1: Data dictionary and rules for functional standardisation ICS 35.240.60; 45.020; 45.060.10 PD CLC/TR 50501-1:2007 This Published Document was published under the

2、authority of the Standards Policy and Strategy Committee on 29 June 2007 BSI 2007 ISBN 978 0 580 52930 6 National foreword This Published Document was published by BSI. It is the UK implementation of CLC/TR 50501-1:2007. The UK participation in its preparation was entrusted by Technical Committee GE

3、L/9, Railway electrotechnical applications, to Subcommittee GEL/9/2, Rolling stock. A list of organizations represented on this committee can be obtained on request to its secretary. This publication does not purport to include all the necessary provisions of a contract. Users are responsible for it

4、s correct application. Amendments issued since publication Amd. No. Date Comments TECHNICAL REPORT CLC/TR 50501-1 RAPPORT TECHNIQUE TECHNISCHER BERICHT May 2007 CENELEC European Committee for Electrotechnical Standardization Comit Europen de Normalisation Electrotechnique Europisches Komitee fr Elek

5、trotechnische Normung Central Secretariat: rue de Stassart 35, B - 1050 Brussels 2007 CENELEC - All rights of exploitation in any form and by any means reserved worldwide for CENELEC members. Ref. No. CLC/TR 50501-1:2007 E ICS 35.240.60; 45.020 English version Railway applications Rolling stock Inte

6、rcommunication between vehicles and train/wayside Part 1: Data dictionary and rules for functional standardisation Applications ferroviaires Matriel roulant Communications entre vhicules et communications sol/train Partie 1: Dictionnaire de donnes et rgles pour la standardisation fonctionnelle Bahna

7、nwendungen Bahnfahrzeuge Datenaustausch zwischen Fahrzeugen bzw. Zug/Strecke Teil 1: Datenkatalog und Regeln fr die funktionale Standardisierung This Technical Report was approved by CENELEC on 2007-01-01. CENELEC members are the national electrotechnical committees of Austria, Belgium, Bulgaria, Cy

8、prus, the Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, the Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland and the United Kingdom. Foreword This Technical Rep

9、ort was prepared by SC 9XB, Electromechanical material on board rolling stock, of Technical Committee CENELEC TC 9X, Electrical and electronic applications for railways. The text of the draft was submitted to vote and was approved by CENELEC as CLC/TR 50501-1 on 2007-01-01. _ CLC/TR 50501-1:2007 2 C

10、ontents Page Introduction 4 1 Scope 7 2 Normative references. 7 3 Terms and definitions 7 4 Reference architecture. 10 4.1 Introduction. 10 4.2 Reference Architecture concept 10 4.3 Requirement for the STD1 Reference Architecture definition 11 4.4 Interacting objects. 12 4.5 Functional Architecture.

11、 20 5 Methods for functional modelling . 24 5.3 Process of function class decomposition. 30 5.4 Modelling accessibility of entities and functions: the pattern view 30 5.5 General modelling rules 31 5.6 Metric Evaluation Criteria 33 5.7 Testing 33 5.8 XML usage 33 5.9 Deliverables 38 6 The Data Dicti

12、onary 39 6.1 Introduction. 39 6.2 Structure. 39 6.3 Requirements for management of the Data Dictionary/model repository. 40 Annex A (informative) Related works . 41 Annex B (informative) Functional addressing in railway specifications 44 Annex C (informative) Process of function class decomposition

13、46 Bibliography . 47 Figure 1 Reference Architecture: Relation cases in the functional communication architecture . 17 Figure 2 General model structure Example. 25 Figure 3 UML Use case diagram Example 26 Figure 4 UML Component diagram Example 27 Figure 5 UML Class diagram Example . 28 Figure 6 UML

14、Statechart diagram Example 29 Figure 7 UML Sequence diagram Example 30 CLC/TR 50501-1:2007 3 Introduction Survey Group SC9XB/SGB1 conclusions From the conclusion of the works of Survey Group SC 9XB/SGB1, in document CLC/SC9XB(Sec)174 (Bibliography 9), a series of standards is to be prepared, with th

15、e following guiding principles: the overall objective is to develop standards for data exchange involving railway vehicle consists, between themselves or with fixed installations; standardisation is focussed to what is necessary for implementing interoperability as defined in Directive 2001/16/EC (o

16、n the interoperability of the Trans-European conventional railway system), and as will be specified by the bodies in charge of drafting Technical Specifications for Interoperability (TSI); the scope of the work is then limited to international Passenger trains and freight trains in The Trans- Europe

17、an conventional rail system, excluding the signalling and control-command subsystem. This does not explicitly exclude High Speed Trains (HST), but excludes formally trams, metros and urban or suburban trains. Separate functional standards will be established for freight and Passenger trains. Require

18、ments for interoperability, including those specified in a set of Technical Specifications for Interoperability (TSI), are different for these two categories of rolling stock. The series of standards has been structured as follows, with four categories: - STD1: data dictionary and rules for function

19、al standardisation; - STD 2: functions in freight traffic (for a selected set of functions); - STD 3: functions in passenger traffic (for a selected set of functions); - STD 4: standardisation of communications procedures. This document is the first part, in category STD1, of the series of functiona

20、l standards, aiming to define a common modelling framework, to be used for the development of the subsequent standards: common methods and rules, a unique Reference Architecture, and common Data Dictionary. The Trans-European conventional rail system Trans-European conventional rail system shall be

21、considered as defined in Article 2 of the Council Directive 2001/16/EC on the interoperability of the Trans-European conventional railway system: For the purposes of this Directive: “Trans-European conventional rail system“ means the structure, as described in Annex I, composed of lines and fixed in

22、stallations, of the Trans-European transport network, built or upgraded for conventional rail transport and combined rail transport, plus the rolling stock designed to travel on that infrastructure. The Trans-European rail system is broken down into subsystems, as described in Annex II of the Direct

23、ive: a) structural area - infrastructure, in particular access / egress points that define the boarders of an infrastructure managed by a given organisation, and also shunting, freight terminals and stations, - energy, electrification system, - control and command and signalling, to command and cont

24、rol train movement, - traffic operation and management, including train driving, traffic planning and management, CLC/TR 50501-1:2007 4 - rolling stock, including all train equipment and man-machine interfaces for driver, on-board staff and passengers. b) operational area - maintenance, including lo

25、gistics centres for maintenance work and reserves for corrective and preventive maintenance, - telematics applications: freight services and passenger services (including passenger information, reservation and payment, luggage management, connections between trains and other modes of transport). Exa

26、mples of functions to be standardised NOTE In the following informal function descriptions, interface ”type B” (“train level to consist level”, named also “train to consist” for short), and interface ”type C” (train to ground) are used (see Figure 1 in 4.4.2). 1) Dynamic passenger information system

27、. Refer to 14, a contribution of TrainCom European Research Project (ref: IST-1999-20096), proposing a detailed XML specification of messages that are exchanged between vehicles and with the ground. This specification covers all characteristic features of the rail environment, including its dynamic

28、aspects. 2) Maintenance: Euromain European Research Project (ref: IST-2001-34019) proposes detailed XML specifications for data, and including the definition of functions for real time monitoring, data collection and statistics. 3) Passenger emergency brake: The Technical Specification for Interoper

29、ability (TSI) relating to the rolling stock subsystem (High Speed) gives requirements for this function. This is a train level function. If the train is formed by several coupled consists, an interface “train to consist” (type B) is involved. A communication with the ground is also possible: interfa

30、ce “train to ground” (type C). 4) “Stabled ready for use”: This is a train level function, ensuring that a train composition is ready for service when required. If the train is formed by several coupled consists, an interface “train to consist”, (type B) is involved. A communication with the ground

31、is also possible for triggering train preparation: “ground to train” interface (type C). 5) Control of passenger lighting: Control of lighting from the driver cab, for two consists coupled together. There are in addition some local controls in each coach. Level of services for the lighting system ma

32、y be different for the two consists - version 1, with two levels of lighting: full, reduced, - version 2, with three levels of lighting: full, reduced, and night. The issue raised by this example is one problem of interoperability among a set of heterogeneous consists. EXAMPLE When the driver is in

33、the consist which is fitted with version 1, how to specify the interface between consists, in order to have an acceptable behaviour in the other consist fitted with version 2. Two alternative solutions are - each consist should be able to interpret in its own way every possible command issued by ano

34、ther leading consist. For instance, a consist fitted with version 1 will set “reduced level” when receiving a “night level” command, - the driver could control each consist after having “imported” on the cab MMI the specific control interface of the given consist. CLC/TR 50501-1:2007 5 6) Train inte

35、grity (completeness of train) Some possible solutions to check the completeness of the train may use - connector at the end of the train, - with GPS + EGNOS, precision 2,5 m possible, - GPS with integrated inertial system. The positions at the train extremities are measured, and compared to the trai

36、n length obtained by summing all vehicles lengths, obtained for configuration data stored in the UIC gateways. Safety integrity requirement SIL 4 is needed for ERTMS level 3 for train integrity function. 7) Establishing and distributing time and date A train level function. If there are several cons

37、ists, clocks have to be synchronised train wide. A problem to solve is how to take into account variable network propagation delay for synchronisation messages. An another issue is standardisation of reference time source, and synchronisation protocols. 8) Establishing and distributing speed A train

38、 level function. Speed data has to be time-stamped. If there are several consists, clocks have to be synchronised train wide (by function distributing time and date). A problem to solve is how to take into account variable network propagation delay. The precise requirements on this function depends

39、of the various consumers of the speed information, requesting various quality of service. CLC/TR 50501-1:2007 6 1 Scope This Technical Report will define - requirements for the methods to be used for functional standardisation, in the standards to be prepared for data exchange involving railway vehi

40、cles, in two contexts 1) inter-consists communication, within a train formation, 2) communication with ground based installations. - the Reference Architecture defining the essential functional interfaces, - the concept of a central Data Dictionary/repository to be applied to freight and passenger t

41、raffic functions. In this context, data are to be limited to basic information elements, which are necessary to define standard messages required for interoperability, and displayed on the interfaces of the communicating entities. Entering Data Dictionary will provide full definition of a data eleme

42、nt, along with its essential attributes at conceptual level. The purpose, in the perspective of the standards to be prepared, is to document the data element pertinent to the functional area and essential for interoperability, to allow the reuse of data element among functional area systems, and fac

43、ilitate data interchange among the systems. NOTE Data Dictionary shall be designed to provide a structural framework that enables continued growth and enhancement of the scope of defined data. Rationale for this requirement is that it is difficult, when defining the scope of a proposed system to ful

44、ly define the application domain and all included interoperability related data. In addition over time, functional requirements will expand. 2 Normative references The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited

45、applies. For undated references, the latest edition of the referenced document (including any amendments) applies. Object Management Group Inc. (http:/www.omg.org) , July 2004, Unified Modelling Language Specification - version 1.4.2 (OMG reference formal/04-07-02), identical to ISO/IEC 19501:2005(E

46、). Extensible Markup Language (XML) 1.0 (Third Edition) W3C Recommendation, 4th February 2004, Franois Yergeau, Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler. 3 Terms and definitions For the purposes of this Technical Report, the following terms and definitions apply. 3.1 abstraction simil

47、ar as view. When using the word abstraction we put into evidence that such view ignores some details that are considered not relevant for its purposes, even if these details are still relevant for the model 3.2 actor class (UML) coherent set of roles that users of use cases play when interacting wit

48、h these use cases. An actor has one role for each use case with which it communicates CLC/TR 50501-1:2007 7 3.3 attribute named property of a class that describes a range of values that instances of that class might hold. The perceived aspect or representation of a property. Attributes may be valued

49、.Attributes are further categorised as intrinsic attributes that are inherent to an entity, and extrinsic attributes that are of a relational nature 3.4 class collection of objects having the same attributes. A class is a named description of a set of objects that share the same attributes, operations, relationships, and semantics. These objects can represent real- world things or conceptual thing