CLC TR 50501-1-2007 Railway applications C Rolling stock C Intercommunication between vehicles and train wayside C Part 1 Data dictionary and rules for functional standardisation《轨.pdf

1、PUBLISHED DOCUMENTPD CLC/TR 50501-1:2007Railway applications Rolling stock Intercommunication between vehicles and train/wayside Part 1: Data dictionary and rules for functional standardisationICS 35.240.60; 45.020; 45.060.10g49g50g3g38g50g51g60g44g49g42g3g58g44g55g43g50g56g55g3g37g54g44g3g51g40g53g

2、48g44g54g54g44g50g49g3g40g59g38g40g51g55g3g36g54g3g51g40g53g48g44g55g55g40g39g3g37g60g3g38g50g51g60g53g44g42g43g55g3g47g36g58PD CLC/TR 50501-1:2007This Published Document was published under the authority of the Standards Policy and Strategy Committee on 29 June 2007 BSI 2007ISBN 978 0 580 52930 6Na

3、tional forewordThis 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 GEL/9, Railway electrotechnical applications, to Subcommittee GEL/9/2, Rolling stock.A list of organizations re

4、presented 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 its correct application.Amendments issued since publicationAmd. No. Date CommentsTECHNICAL REPORT CLC/TR 50501-1

5、RAPPORT TECHNIQUE TECHNISCHER BERICHT May 2007 CENELEC European Committee for Electrotechnical Standardization Comit Europen de Normalisation Electrotechnique Europisches Komitee fr Elektrotechnische Normung Central Secretariat: rue de Stassart 35, B - 1050 Brussels 2007 CENELEC - All rights of expl

6、oitation 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 Intercommunication between vehicles and train/wayside Part 1: Data dictionary and rules for functional standardisation

7、 Applications ferroviaires Matriel roulant Communications entre vhicules et communications sol/train Partie 1: Dictionnaire de donnes et rgles pour la standardisation fonctionnelle Bahnanwendungen Bahnfahrzeuge Datenaustausch zwischen Fahrzeugen bzw. Zug/Strecke Teil 1: Datenkatalog und Regeln fr di

8、e funktionale Standardisierung This Technical Report was approved by CENELEC on 2007-01-01. CENELEC members are the national electrotechnical committees of Austria, Belgium, Bulgaria, Cyprus, the Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, La

9、tvia, Lithuania, Luxembourg, Malta, the Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland and the United Kingdom. Foreword This Technical Report was prepared by SC 9XB, Electromechanical material on board rolling stock, of Technical Committee CENELEC TC 9

10、X, 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 Contents Page Introduction 4 1 Scope 7 2 Normative references. 7 3 Terms and definitions 7 4 Reference architecture

11、. 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 . 20 5 Methods for functional modelling . 24 5.3 Process of function class decomposition. 30 5.4 Modelling accessi

12、bility 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 Dictionary 39 6.1 Introduction. 39 6.2 Structure . 39 6.3 Requirements for management of the Data Dictionary/model rep

13、ository. 40 Annex A (informative) Related works . 41 Annex B (informative) Functional addressing in railway specifications 44 Annex C (informative) Process of function class decomposition 46 Bibliography . 47 Figure 1 Reference Architecture: Relation cases in the functional communication architectur

14、e . 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 Statechart diagram Example 29 Figure 7 UML Sequence diagram Example 30 CLC/TR 50501-1:2007 3 Introduction Survey

15、 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 the following guiding principles: the overall objective is to develop standards for data exchange involving railwa

16、y 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 (on the interoperability of the Trans-European conventional railway system), and as will be specified by the bodie

17、s 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-European conventional rail system, excluding the signalling and control-command subsystem. This does not explicitly exc

18、lude 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. Requirements for interoperability, including those specified in a set of Technical Specifications for Interoperability (

19、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 functional standardisation; - STD 2: functions in freight traffic (for a selected set of functions); - STD 3: functions i

20、n 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 functional standards, aiming to define a common modelling framework, to be used for the development of the subsequent stan

21、dards: 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 considered as defined in Article 2 of the Council Directive 2001/16/EC on the interoperability of the Trans-Europ

22、ean 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 installations, of the Trans-European transport network, built or upgraded for conventional rail transport and combi

23、ned 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 Directive: a) structural area - infrastructure, in particular access / egress points that define the boarders of an inf

24、rastructure managed by a given organisation, and also shunting, freight terminals and stations, - energy, electrification system, - control and command and signalling, to command and control train movement, - traffic operation and management, including train driving, traffic planning and management,

25、 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 logistics centres for maintenance work and reserves for corrective and preventive maintenance, - telematics applica

26、tions: freight services and passenger services (including passenger information, reservation and payment, luggage management, connections between trains and other modes of transport). Examples of functions to be standardised NOTE In the following informal function descriptions, interface ”type B” (“

27、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. Refer to 14, a contribution of TrainCom European Research Project (ref: IST-1999-20096), proposing a detailed X

28、ML 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 aspects. 2) Maintenance: Euromain European Research Project (ref: IST-2001-34019) proposes detailed XML specifica

29、tions for data, and including the definition of functions for real time monitoring, data collection and statistics. 3) Passenger emergency brake: The Technical Specification for Interoperability (TSI) relating to the rolling stock subsystem (High Speed) gives requirements for this function. This is

30、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: interface “train to ground” (type C). 4) “Stabled ready for use”: This is a train level function, ensuring that a train

31、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 is also possible for triggering train preparation: “ground to train” interface (type C). 5) Control of passenger

32、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 may be different for the two consists - version 1, with two levels of lighting: full, reduced, - version 2, with th

33、ree 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 the consist which is fitted with version 1, how to specify the interface between consists, in order to have an ac

34、ceptable 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 another leading consist. For instance, a consist fitted with version 1 will set “reduced level” when receiving a “ni

35、ght 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 integrity (completeness of train) Some possible solutions to check the completeness of the train may use - connector

36、at the end of the train, - with GPS + EGNOS, precision -classes defining the behaviour. CLC/TR 50501-1:2007 27 Activities: - for each interface: define functions for the received messages; - for each interface: define attributes for data exchanged through the interface periodically. (Formally, the u

37、se of attributes in an interface is a violation of the UML 1.4 definition, but with UML 2.0 this will also be allowed. It is also allowed presently by some UML tools); - define classes for all data structures used as parameters or structures that are used for configuration; - define classes which re

38、alize the components interfaces, with all necessary attributes and functions; - the class diagram below, in Figure 5, shows the detailed interfaces of the EmergencyBrakeControl-component from above; - the interfaces are identical to those shown in the component diagram above; - the classes shown bel

39、ow all reside in the component EmergencyBrakeControl and the class BrakeControl realizes the EmergencyBrakeControls interfaces; interfaceAlarmOutput+ activateAlarm ( )interfaceDriverEB+ activateEmergencyAlarm ( )+ recordAlarmMessage ( )+ activateBrake ( )+ releaseBrake ( )interfacePEHUInput+ handleO

40、perationDetected ( )ControlBrakeControl+ currentStatus : BrakeControlStatus+ timeoutAlarmMSec : UINT = 1000signal Error(code : UINT)Data TypeEBControlParams+ suppressAlarm : BOOL = FALSE+ suppressRecording : BOOL = FALSEsignalError+ code : UINTinterfaceEmergencyBrakeStatus+ readOnly brakeApplied : B

41、OOL+ setParameters ( in p : EBControlParams ) : BOOL+ activeParameters1enumerationBrakeControlStatusActiveInactiveErrorFigure 5 UML Class diagram Example - add behavioural definition of classes: define state chart for classes (see diagram below); - use states for defining activities (such as waiting

42、, alarming); - only use interface function-calls, signals and changes of attribute values, signals or timeouts as state transition triggers; - use actions (preferably not at transitions, only within states) to precisely define the activities associated with a state or a state transition (such as changing values of variables or sending messages or calling other functions). CLC/TR 50501-1:2007 28