|We present a seemingly very detailed enumeration.
|It is structured casually, not the result of
any deeper concept formation.
|If it had been "final", then the challenge
might not have been a
|The current author could wish for a better
characterisations than the
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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:
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
We exemplify some domain perspectives.
Railway system owners are concerned with setting and achieving certain
Domain descriptions ideally should serve as a basis for understanding,
modelling, analysing and predicting and monitoring (the state of) such
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
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:
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 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 -
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!
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
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
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.
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
Contractors interface with consultants and infrastructure owners and
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
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":
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.
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
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.)
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:
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.
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.).