Railway Systems:

• Railway Components:

  One may look at a railway system by decomposing its "entirety" into many components, or by viewing components in isolation, or one may look at the system as the composition of these components. The views are complementary and inter-dependent.

  By an "entire" railway system we understand all that there possibly can be said to have one `railway' attribute or another. By a component we understand any sub-part of those `railway' attributed `parts'. Some such component identifications are more reasonable, more fitting, more analysable and more compositional than others. Other decompositions lead to ackward component interfaces and to difficult analyses. Decomposition and composition is basically an art, especially for such systems which are new or unfamiliar. For well-established systems, such as railways, we take our departure point - with respect to "componenthood" - in existing practice, that is: reflecting established management structures.

  The decomposition of this section is rather "speculative". It is expected that a much clearer and more relevant decomposition will emerge as railway professionals provide input.

  • The Net:

    A domain description of railway nets must make precise what is meant by a net, its composition of rails, be they linear or curved simple pairs, or junctions, or crossovers, etc., the means of switching junctions and switchable crossovers, the means of setting signals, etc. Also the meaning of routes, open and closed in a net, of inserting and removing parts of the net (as in construction, maintenance or downsizing), etc., must be handled by a domain description.

  • Time-tables:

    A domain description of time-tables must make precise all forms of such: those seen by passengers and those seen by schedulers, despatchers, signalling staff, engine men, etc.

  • Scheduling & Allocation:

    There are different levels of scheduling & allocation: from strategic via tactical to operational concerns.

    • Upgrading / Downsizing:

      A domain description of issues close to strategic concerns of upper-level management include descriptions of when main resources should be acquired or disposed: when new lines or high speed trains should be introduced, etc.; when capital should be converted into such facilities; when existing facilities should be discontinued; or converted into capital. Etcetera.

    • Spatial Resource Scheduling and Allocation:

      A domain description of the tactical aspects of scheduling and allocation must make precise such things as scheduling (in time) and allocation (in space, rail net topologically) of trains to routes according to time-tables. The issues of scheduling constraints and rescheduling causes must likewise be made precise. Route planning is part of this: optimal use of single line streches between stations (incl. tunnels), of individual station topologies, etc.

    • Task Scheduling and Allocation:

      A domain decription of the operational resource management aspects of signalling includes description of the rules & regulations normally characterising plans for the setting of junctions and signals.

    • &c.

  • Traffic - Monitoring & Control:

    Train traffic is the timewise progression of trains across the net. Task scheduling and allocation prepares the plans to be followed in traffic monitoring and control.

    • Signalling:

      A domain description of traffic must include the description of the procedures whereby junctions are actually switched and signals set according to plans. Further a domain description of this facet must include the sensing of train positions, road level gates, etc.

    • Despatch:

      A domain description is expected to cover the layout, use and update of train running maps, including the current interface between despatchers and train engine men and the future automatic control interface between stationary and mobile control centers.

    • Monitoring:

      A domain description is to cover means and ways of locating trains (and rolling stock) - including descriptions of the technology by means of which we record train locations and relate these to plans.

    • Control:

      A domain description must include varieties of control: from manual via partial (semi-) to fully automatic control of the despatch of trains and of the setting of junctions and signals. These descriptions include real-time and safety critical aspects.

    • &c.

  • Rolling Stock:

    By rolling stock we understand the freight cars, passenger wagons, locomotives, etc., that make up trains. At any one moment (in time) some such stock stand idle on tracks at stations, others are being shunted around the main parts of stations, or are being marshalled in freight yards, or are subject to maintenance or preparation, or are part of scheduled trains.

    • Shunting:

      A domain description models (correct as well as incorrect) shunting procedures: The movement of rolling stock within a station proper (but outside the marshalling yard) - plans and their enactment.

    • Marshalling:

      A domain description models (correct as well as incorrect) marshalling procedures: The movement of rolling stock within a marshalling yard (but outside the station proper) - plans and their enactment.

    • Monitoring & Control:

      A domain description models the whereabouts of rolling stock, statically and dynamically, and the composition and decomposition of trains: sets of waggons etc.

    • Maintenance and Repair:

    To be written

  • Passenger Handling:

    To be written

  • Freight Handling:

    To be written

• Stake-holders:

  The railway system, as also the larger domain of general transport systems (trains, busses, taxis, ships, aircraft, etc.), can be seen from different perspectives. The people representing these perspectives, the stake-holders, look at the overall railway system domain differently - focusing "on their own" concerns.

  In order to secure, in future, railway systems - including, in the context of the present document, railway software systems - we must express requirements to desired new software support in terms of all the relevant stake-holder perspectives. To do so (ie., express appropriate requirements perspectives) we must establish and analyse normative and instantiated descriptions of the railway domains from each of these perspectives. These descriptions will then serve as reference points for requirements descriptions - as well as for well-nigh any management (planning, design, operation).

  Stake-holders are tightly related to specific components of the infrastructure.

  We exemplify some domain perspectives.

  • Owners:

    Railway system owners are concerned with setting and achieving certain socio-economic objectives.

    Domain descriptions ideally should serve as a basis for understanding, modelling, analysing and predicting and monitoring (the state of) such objectives.

  • Management:

    Railway system management is concerned with (i) strategic, (ii) tactical and (iii) operational issues such as (i) upgrading or downsizing resources (acquiring new material, respectively sell of parts - i.e. conversion of one kind of resource to another: goodwill to new capital, capital to new lines, stations, rolling stock, services, etc.), (ii) spatial scheduling and allocation of resources (where should resources be approximately in which time intervals), and (iii) task scheduling and allocation (to which particular tasks should a resource (a staff member, a wagon, etc.) be bound), etc.

    Domain descriptions should help management in achieving best possible support for these and other resource management issues - with the domain descriptions serving as a basis for the requirements specification and procurement of [for example] computerised decision support systems.

  • Operational Staff:

    Operational staff carries out the actions as decided and monitored by management. Examples of some classes of operational staff, each (class) again with their own sub-perspectives (views) of the overall domain, are:

    • Schedulers/Reschedulers

    • Despatchers

    • Signal Engineers

    • Engine Men

    • Ticket Clerks

    • Freight Handlers

    • Marshalling Yard Staff

    Each of these groups of ground level staff need be supported in their function by computing. Proper perspective domain descriptions shall help secure that appropriate function software can be procured, developed and used effectively. The need for increased integration of functionalities across each of the above sub-staff disciplines and between these and for exampe management computing systems, mandate that the overall domain descriptions be checked for concordance and that the individual program packages be based on "backbone, software bus" systems that allow freeest possible exchange of data and invocation between the packages.

  • Passengers:

    Passengers need be informed about possible journey routes, schedules and fares; passengers reserve, buy, cancel or consume tickets; and passengers need be informed about the progress of their journey - ahead!

    Appropriate railway system domain descriptions must reflect this and permit the procurement, development and effective use of software that automate or supports the above passenger functionalities - and more!

  • Freighters:

    People and enterprises send and recieve freight. Railways offer freight transport. Full-function inter-modal source-to-target transport (truck, rail, ship) and the provision of this service by a variety of service operators put an extra demand on railway system descriptions.

    The domain descriptions must therefore enable transport operators to design and operate increasingly versatile, economic and faster such services - as supported by computing systems.

  • Railway System Suppliers:

    The planning, design, construction and day-to-day operation of railway systems - whether of their infrastructure or their operator owners - require that these owners and operators make use of a plethora of suppliers. Each of the diverse supplier classes have their view of the railway system.

    To secure optimal supplier/consumer relations we [must] establish domain descriptions which lay bare as much of these views of the railway system as possible.

  • Consultants:

    Consultancy firms help the railway system infrastructure owners and operators plan and design new and improve existing services: net - including signalling, electricity, etc. - components, scheduling & allocation support, rolling stock, etc.

    Consistent domain descriptions secure that the interface between infrastructure owners and operators - on one side - and consultants - on the other hand - is "free from noise": that is as precise as possible. Contractors:

  • Contractors:

    Contractors interface with consultants and infrastructure owners and operators.

  • Operations Suppliers:

    Examples of operations suppliers are: electricity, oil, food stuff, paper, etc., etc.!

    A full-spectrum railway system domain description will help pinpoint and make precise many, but probably never all, possible operational supply interfaces - and will help in the procurement, development and effective use of software packages for the support of supply ordering and delivery.

  • IT, incl. Software Suppliers:

    IT, especially software package and system developers form an important class of stake-holders. They have been mentioned implicitly in all of the above other stake-holder perspectives.

    So we here repeat that railway system domain descriptions form the basis for the specification of requirements (i.e. procurement) and hence the development of software.

  • "The Public at Large":
    • Environmentalists
    • Tax-payers
    • Politicians
    • &c.

  • &c.

• Railway Facets:

  One can "look" at an entire railway system - at each of its many components and from the perspectives of each of its many groups of stake-holders - at different levels of abstraction.

  It seems a good description principle to present the seeming complexity of domain concepts by a succession of abstractions: "from big LIES, via increasingly smaller Lies and lies to truths!"

  Any one domain component and perspective is not necessarily described by a single sequence of such description `refinements'. Rather one may expect a hierarchy of concordant, i.e. relatable descriptions.

  • Intrinsics:

    The very basics of a domain must first be described. We also call that the domain intrinsics. As will be clear from the subsequent, non-intrinsic facets, the intrinsics cover those properties of a domain which are invariant under whichever form the supporting technologies, the procedural (operational) rules & regulations, the human behaviour, etc. may take.

    In the intrinsics of a railway net we typically abstract the ways in and means by which the support technology works. The rules & regulations - for example for the proper obeyance of line signals - are usually abstracted as "feature-less scripts", that is as prescriptions (scripts) which allow any one of a set of behaviours ranging from intended ones via erroneous to criminal conduct! And in the intrinsic description of human behaviour one then describes the conditional probabilistic selection of choices and actions (according to scripts).

    Abstract formal descriptions of domain intrinsics can usually be expressed in some classical algebraic or model-oriented specification language (OBJ, CafeOBJ, CASL, VDM-SL, RSL, Z or other.)

  • Business Processes:

    To be written

  • Support Technologies:

    Support technology for signalling has changed over the years: from a person waving a flag (i.e. manually), via the electro-mechanical hoisting or lowering of a pole-mounted metal plate, and the on and off switching of coloured lamps, to the software controlled and electronics effected setting and resetting of bits and lamps in the "cockpit" of the engine man.

    Railways feature many supporting technologies: not just the signalling technology mentioned above. Support technologies exist for the movement of point machines (switches, junctions) - including those of cross-overs, for the sensing of train positions (mechanical and optical sensors), for the hoisting and lowering (or opening and closing) of gates at road level crossings, setting and resetting of passenger information display boards, etc.

    Abstract domain descriptions of supporting technologies usually entail descriptions of their real-time and failure characteristics. Usually some temporal logic is used: interval temporal logic, a logic for reactive systems, some duration calculus or another, etc.

  • Management & Organisation:

    To be written

  • Rules & Regulations:

    The operation of many infrastructure components are guided by rules & regulations: prescriptions to be followed, usually by human operators. Examples are legio. For railway systems there are rules & regulations concerning the calculation of passenger ticket and freight fares, for the advice of passengers and freighers when enquiring about special rebates, for the scheduling and re-scheduling of trains, etc. Specific examples are: passengers must be informed about cheapest fares, or no two or more trains may arrive at or depart from a station in any given (for example two minute) interval, etc.

    Abstract descriptions of domain rules & regulations - since they typically are vouched in descriptive language - may best be expressed in some classical, novel, or even exotic logic: from classifaction via predicate to higher order logics, or in some modal (temporal) or other logic: default logic, belief logic, deontic logic, [auto-]epistemic logic, non-monotonic logic, etc.

  • Human Behaviour:

    Humans operate or use the facilities of infrastructure systems. And humans may do so as intended, correctly, or may fail to do so. Either because they, as humans do, make mistakes, or because they maliciously tamper with the system.

    Abstract descriptions of human behaviour possibly appeal also to fuzzy or probabilistic logics and other such calculi (fuzzy sets, probability theory, etc.).