Dines Bjørner
June 18, 2003: 4:15 amA ``Grand Challenge'':
Domain Models & Theories of
Transportation Systems & Logistics
CSE: Computer Science and Engineering
IMM: Informatics and Mathematical Modelling
Building 322, Richard Petersens Plads
DTU: Technical University of Denmark
DK-2800 Kgs.Lyngby, Denmark
E-Mail: db@imm.dtu.dk, URL: www.imm.dtu.dk/~db
Transportation by means of public transport, busses, trains, ships and air planes, is increasingly becoming monitored and controlled by computing and communication (C&C). From a situation in which many diverse such C&Cs were developed and acted in isolation, we increasingly find that these ``individual'' C&C (hardware and software) components are linked together and interact: Share data, and even control.
Yet there is no underlying, common understanding, ``written down'', shared amongst many kinds of engineerings (etc.), that somehow ``unite'' the various facets of a domain - such as hinted at in the next section ([2.]).
Mechanical engineers all develop their artifacts based on intimate and explicit knowledge of Newton's laws of mechanics, and of all the results derived from these laws and on further insight gained by physicists since Newton. Electrical engineers all develop their artifacts based on intimate and explicit knowledge of electricity (Ohms laws, Maxwell's equations, etc.). And so on for all engineering endeavours build on the natural sciences.
Software engineers, alone, have no such available theories - of the application areas for which they develop software - to build upon.
There are no established theory/theories of banking (including bank staff and bank client operations and behaviour). There are no established theory/theories of transportation (other than basically those upon which operations research builds (``flow in networks'')) - such as we shall understand transportation, and as outlined in the next section. There are no established theory/theories of health-care, of the flow of people, material, information and control in the health-care sector. And there are no established theory/theories of ``the market'' (such as wee shall delineate that concept in the next section).
Yet software engineers happily, or perhaps it is rather opportunistically, go on developing software without having the slightest idea of such underlying, and constraining theories.
This, then, forms the basis for our challenge: To create such a theory.
In order for us to advance the idea of creating a domain theory of transportation there must be some trust in a core of that domain basically remaining invariant over time. Support technologies, the management & organisation, the rules & regulations of the transport domain may very well change. But something, to which they all refer, must be stable.
We claim that the following concepts of transport are invariant:
and many more !
This section can be skipped in any reading. It presents a set of characterisations of the fields of computer & computing science, domain, requirements and software engineering, and the concepts of domain, requirements, model and theory such as the present author of the current document understands these fields. As such the section ``signals'' the didactics ``from'' which the present author of the current document understands the challenge being put forward.
We ``risk'' some characterisations:
By a(n application) domain we understand an area of (possibly computing supportable) human activity -- such as a bank and its interfaces to its customers, other banks, regulatory agencies, etc.
We are to understand, in the ``narrow'' context of the term `domain', such a domain void of any reference to computing not already in the domain. That is: If the purpose of our trying to understand a domain is - later on - to install computing /and communication) in support of activities of the domain, then (requirements to, let alone software of) that future computing (and communications) is not to be mentioned in the domain.
This domain is a major infrastructure component, ie., is a socio-economically driving force of a country, or a region, in securing that area's social and economic structure and well-being.
To `The Financial Service Industry' we ``count'' the sets of such enterprises as banks, insurance companies, securities institutions (trader, brokers and exchanges), venture capatial firms, etc., as well as the country's and/or region's regulatory agencies. We also ``count'' all the clients of these enterprises, including politicians.
To describe `The Financial Service Industry', to us, means to describe all those enterprises, agencies, clients, etc., as well as their interaction. To wit: The opening and closing of accounts, as well as all the varieties of transactions ``against'' accounts: Deposits, withdrawals, transfers, etc.
This domain is a major infrastructure component, ie., is a socio-economically driving force of a country, or a region, in securing that area's social and economic structure and well-being.
To `Transportation & Logistics' we ``count'' the sets of such enterprises as railway (bus, shipping, air) infrastructure owners (eg., the railway net (resp. roadnet, airport, and harbour) owners), railway (bus terminal and road net [toll way etc.], harbour and canal, airport and air traffic control) infrastructure operators (operating the nets: Lines and stations, signalling, etc., resp. bus deports and toll ways, harbours and canals, airport), train (bus, shipping, airport and air traffic) service providers (on shared transport nets), regulatory agencies, clients (ie., passengers, companies wishing to transport freight, etc.), providers of services to the above (equipment manufacturers, net (bus depot and road net, harbour and canal, aiport and air traffic control center) construction firms, travel agencies, etc.), and especially logistics firms (which offer services to freight customers: Arranging composite transfer of goods via combinations of rail (freight train), road (truck), ship (boat), and air (cargo).
To describe `Transportation & Logistics' means to describe all those enterprises, agencies, clients, etc., as well as their interaction.
Just exemplifying for railways we briefly mention the entities, functions and behaviours of the specific domain: (1) The net (lines and stations), (2) the trains, (3) the net operations (signalling, stations, etc.), (4) the despatch: monitoring and control of trains, (5) the handling of passengers and freight, (6) the planning, development and phasing-in of new lines and stations and the phasing out of lines and stations, of new train services, (7) the scheduling and allocation of: (7.i) time-tables, (7.ii) rostering of train crews, (7.iii) the composition and decomposition of trains, (7.iv) train maintenance, etc., etc.,
Similar outlines can be given for bus transport, for shipping, and for air transport.
This domain is a major infrastructure component, ie., is a socio-economically driving force of a country, or a region, in securing that area's social and economic structure and well-being.
To `Health-Care' we count such enterprises as (1) healthy and sick people (ie., potential or actual patients), (2) private (family doctor) physicians, ie., general practitioners and specialist medical doctors, (3) community nurses, (4) hospitals, (5) ambulance services, (6) clinics (convalescence and special treatment), (7) pharmacists, (8) health insurance companies, (9) interfaces to the pharmaceutical industry, (10) the national board of health, (11) ministry of health, etc.
To describe `Health-Care', to us, means to describe all those enterprises, agencies, clients, etc., as well as their interaction. To wit: Patient visits to family physicians, pharmacies, clinics, and hospitals, the actual functions performed at these places: analyses, diagnostics, treatment and treatment advice (incl. medication and their prescription), check-up on results of treatments, etc., MR and CT scanning, surgical operations, etc. Patient interaction with health insurance institutions: Registration, premium payments, claims, etc. Medical doctor, community nurse, clinic, pharmacy and hospital reportings to health authorities, etc.
By ``The Market'' -- for goods (merchandise) and services we mean the aggregation of government agencies (G), businesses (B) and citizens (C). Here government institutions include such as social welfare, excises & tax, etc.; businesses include producers, wholesalers and retailers -- seen from the point of view of their interaction, and retailer interaction with consumers (ie., citizens). And citizens cover all of us in our relations to government agencies, businesses (usually retailers, agents on behalf of these, and brokers between them and citizens), and to other citizens (in for example citizen associations (societies), etc.).
To describe ``The Market'' , to us, means to describe, from the point of view of the G2G, G2B, G2C, B2G, B2B, B2C, C2G, C2B, and C2C interactions, all those interacting ``players'' belonging the sets G, B and C. For example, the C2B (where B is a retailer) interactions are for example: (C) Inquire as to whether a retailer has a certain merchandise, price, delivery time, etc., (B) acknowledge such an inquiry, (C) order merchandise, (B) acknowledge or declien an order, (B) deliver ordered merchandise, (C) accept or reject delivery, (B) invoice delivery, (C) pay invoice, (C) return merchandise for repair or replacement, etc.
Similar such interactions can be identified for each of the remaining G2G, G2B, G2C, B2G, B2B, B2C, C2G, and C2C.
In understanding a domain it seems advicable that one decomposed and ``serialises'' one's understanding into the understanding of a number of related facets. A facet is a way of viewing a thing, in this case `the domain'. We suggest to at least view a domain from the point-of-view of the folowing facets.
By the intrinsice of a domain we understand those properties, of a domain, which any other facet/view is based on. That is, each of the next facets to be treated all have their treatment, their understanding, their description, depend on there first being established an understanding of the very basics, the intrinsics.
Example: We pursue the example of railways: It seems that whoever you are, a railway owner, a net operator, a train operator, a passenger, etc., (1) the net: the fact that there are stations and that some of these are ``non-stop'' connected by (rail) lines, and (2) the trains, running on the net, along lines and between stations, that that is part of the intrinsics of a railway system.
By the supporting technologies of a domain we understand those facilities, of a domain, other than human actors, which support operations of the domain.
Example: In ``ye olde days of railways'', switches (turn-outs, points, etc.) - units along the rail where a route through the rail units merges or diverges - were handled by humans throwing, by the shear force of their muscles, these switches. Later the switches became operated by mechanical means: From a cabin tower, levers, mechanical momentum amplifiers and wires connected, sometimes hundreds of feet away, to the switches. Yet later, to illustrate a thrid kind of supporting technology, the mmechanics was extended into electro-mechanics. Most recently we find that switches are operated in groups, involving also significant electronics, and, ever more recently, with these operations being controlled by computers.
All of the above exemplified several (``generations'' of) supporting technologies. In current domains we shall today find that several such supporting technologies co-exists. And have to be understood.
By domain management & organisation we understand a structured decomposition of the work of domain staff into usually a hierarchical or a matrix structured organisation where ``lines of command & reporting'' flow along the hierarchical tree or the horisontal/vertical grid of the matrix organisation: Where managers formulate policies, rules & regulations, and issue directives to ``levels below them'' in the structure, where they respond to ``alerts'' and reports from''below them'' in the structure, and where they ``alert'' and report to other managers, or the board, ``above them'' in that structure.
Example: In China, along the rail lines, from station to station, the reschedulng of trains - due to late or early trains - involves certain procedures (ie., management) and certain communications with colleagues in neigbouring stations (ie., organisation), before a proposed new train schedule can be ``universally'' adopted.
By domaon rules & regulations we understand two sets of ``laws'': One set, the regulations, which specify expectations of ``acceptable'' behaviour of equipment and humans; another set, the rules, which stipulate what corrective actions, against equipment, operations, and/or staff, are to be taken in case rules are not fulfilled.
Example: In China, for reasons we shall not endeavour to explain, train traffic into and out of railway stations are expected to satisfy the following rule: In any two minute interval (ie., period), at most one train is allowed to either enter or to leave a(ny) station. The ``pairing'' regulations state how to achieve this, and also stipulates administrative (ie., ``punitive'') measures to be enacted if equipments and/or humans fail to satisfy the rule.
Humans, whether staff of, or clients (customers) or others related to the enterprise, behave either (1) diligently: despatch their work within the enterprise with careful regards to rules & regulations (whether these are explicitly enunciated or are tactily understod), or they behave (2) sloppily, with casual, arrogant or indolent respect for such expected behaviours, or they behave (3) negligently, with somewhat recalsitrant (obstinately defiant of authority or restraint), or they behave (4) outright criminally, explicitly, and on purpose, with a specific, say destructive intent in mind, going against rules & regulations.
To understand a domain is also to understand the possibilities of staff and clients (etc.) to create harmony or havoc.
A doman is also characterised by its stake-holders. These are the various people and institutions ``united'' in separate interest groups - that potentially may have different, possibly inconsistent, either reconcilable or ir-reconcilable (ie., conflicting) views of (on) the domain.
An important aspect of domain identification and construction is to identify, record, and communicate, during the construction process with suitably selected members of each of the selected stake-holder groups. They are the ones from whom to acquire the appropriate domain knowledge, and they are the ones with whom to validate the emerging domain models.
Typically, for a production company one can identify the following stake-holder groups: (i) Oweners, (ii) executive management, (iii) middle management, (iv) ``floor'', ie., ``lowest'' level management, (v) workers (in administration, sales, marketing, design, research, production, etc.), (vi) clients (who buy the products), (vii) suppliers (of parts and materials, power (electricity), water, IT, etc.), (vii) consumer/client organisations, (viii) regulatory agencies, (ix) politicians (who ``meddle'' in well-nigh every matter), (x) neighbours of the production company's sites, (xi) the media (newpapers, radio, TV), and (xii) the general public (``man on the street'').
A model is only acceptable if it reflects the views of each and all of these stake-holder groups. Two (or more) such views may be inconsistently represented in a model (under development) -- in which case one has to inquire whether that inconsistence is due to an oversight on behalf either of the developers (then it can be remedied by them alone), or on behalf of the two (or more) stake-holder groups (in which case some mutual clarification process is needed); or that inconsistence may be due to an inherent conflict between stake-holder groups. In the latter case domain management must be brought in to reconcile the inconsistency.
But, in any case, we can expect a domain model to consist of of a set of judiciously harmonised (integrated, unified) formal models.
By a model we mean a description, both in plain natural (cum national) language, and in formal terms: In any combinations of mathematics and various, one or more, formal specification languages.
A model is not the reality of the domain, only a reflection of it.
Models involve iconic, analogic and analytic facets, are either prescriptive or descriptive, or combinations thereof, and models may also involve variations or combinations of intensionality and exensionality (``white'' versus ``black'' box views).
Models are constructed in order (a) to understand that which is being modelled [ie., the domain], (b) to inform others about that ``thing'', (c) to perform predications about the behaviour of the ``real thing'' (based on computations over the, ie., ``its'' model), (d) to implement computing support for activities of the domain, (e) to perform business process reengineering of operations (human or otherwise) of the domain, (f) or other.
A model usually consists of different types of document parts:
Informative document parts, as the term says, inform: Presents a (1) reason for why the model is constructed, its rationale so-to-speak, that is: The (prior) needs for and (subsequent [planned]) uses of the model (that is: The ``customers''); (2) lists who is constructing, or has constructed, the model (the partners); (3) a budget for and accounts of economic aspects of constructing the models (imcl. project time & resource plans, etc.); and possibly other information.
There usually are four kinds of descriptive document parts:
When initially starting work on a model the developer cum researcher
rough sketches. Rough sketches serve to
form
concepts
based on (ie., around) which the model is eventually
expressed. The concepts are abstractions of ``actual world''
phenomena.
Along the road of model development specific terms of the domain are identified and defined. And these terms eventually enter into some ontology for the domain.
Based on clear concepts, and evolving terminology and ontology, the developer can now formulate, in precise, but informal, natural and professional (term) language a description of the entities, functions and behaviours (events, interactions and processes) of the domain.
Usually the narrative goes hand-in-hand with a set of one or, usually more, formalisations, ie., formal specifications. Usually one formalism does not suffice. It appears that no one specification language can equally elegantly and expressible model all domain attrubutes, facets and stake-holder perspectives. One is therefore forced to use several formalisms.
We alphabetically mention a few formalisms: ASM (Abstract-State Machines) (since early 1990s), B (``Bourbaki'') (since early 1990s), CASL (Common Algebraic Specification Language (since 1997), CafeOBJ (since 1997), DC (Duration Calculi) (since 1990), ITL (Interval Temporal Logic) (since late 1980s), RAISE (Rigorous Approach to Industrial Software Engineering) (since 1986), TLA+ (Temporal Logic of Actions + Set Theory) (since mid 1990s), Petri Nets (since 1963), CSP (since 1978), Statecharts (since mid 1980s), pi-Calculus (of Mobile Processes) (since late 1990s), VDM (Vienna Development Method) (since 1973), and Z (``Zermelo'') (snce 1980).
We refer to Recent Trends in Formal Techniques and Tools for Software Development for Transportation Applications - A Survey and TLA+ as sources for references to the above-listed approaches to formal specifications.
It is to be hoped that a set of theories can be brought about, theories which ``unify'' pair- or triple-wise combinations of the above and other formal method approaches. We refer to Unifying Theories of Formal Methods - Integrating Formal Methods
Analytic document parts arise as the result of analysing descriptive document parts.
There usually are four kinds of analytic document parts:
When models are formalised, then it is possible to derive properties from the model that are believed to be properties of the domain (being modelled). The set of axioms and inference rules upon which the formal description of the models are based, as well as the possible lemmas, propostions and theorems derived from those axioms and deduction rules, form a theory.
See the last two entries itemised above.
Computing systems engineering, to us, is concerned with the development of hardware + software solutions to problems. As such it involves software engineering and hardware engineering and their interplay, usually referred to as co-design. We shall only further characterise software engineering.
Software engineering, to us, is a convergence, a fusion, between domain engineering, requirements engineering and software design - in the context of computer systems engineering, ie., with due considerations, also, of interfaces to hardware.
Domain engineering - in the light of the above, to us - is concerned with the analysis and syntehsis (ie., construction), ie., development of domain models (incl., domain theories) - thus with due respect to all relevant stake-holder groups.
Requirements engineering, to us, is concerned with the development of requirements. At this place in our presentation we shall not mention the relevant issues of requirements acquisition and validation, but focus exclusively on the structure of a (set of) requirements models.
But first we need a crucial definitions:
We postulate that there are basically three requirements document parts, either presented, in the model, separately, or intertwined, but in a clearly recognisable fashion:
Hence:
Wirhnin `Domain Requirements' we can identify a number of principles and techniques that huide us in their construction and expression. We mention some:
Usually a domain model consists of very many specfications and covers a large ``terrain''. For any specific requirements only a fraction of the domain is relevant. Projection is like an algebraic operation which ``narrows'' the domain model into those parts of relevance to the requirements.
Usually a domain behaviour is non-deterministic and so are, therefore, its models. Determination is like an algebraic operation which removes undesired non-determinisms.
Sometimes domains do not admit certain kinds of functionalities: They are simply not (humanly or, up to this moment, technologically) feasible. With the advent of computing and communication some such functionalities are now made feasible. Extension is like an algebraic operation which extends, basically the domain - but phrased, usually, within the requirements.
Normally a domain model generically covers sets of domain instances: Many different railway systems, or may different health-care systems, etc. Instantiation is like an algebraic operation which binds certain loosely specified properties of a generic doman model to specific such properties. Examples could be: (1) A specific set of train despatch rules & regulations - although even these may be left ``programmable''; or (2) a specific kind of railway net topology, topologically bound by certain kinds of local practices.
Normally required software is to work together with pre-existing hardware and software sub-systems. And although basically a machine requirements (ie., a platform) issue, we consider fitting like an algebraic operation which concretises certain domain properties in certain directions as biased by the chosen pre-existing hardware and software sub-systems.
Invariantly the required software, before installation, need be initialised to some basic data, ie., an initial database need be established, or an existing need be migrated. Initialisation binds certain facets of domain configurations to to static, ie., contextual ``values'', while others are initially set to some dynamically changing initial ``values''. Initialisation requirements further prescribe how the configuration contexts and states may be kept ``up-to-date''.
By software design we understand the derivation, from requirements, of provably correct software.
The design process can be structured, for example, as follows:
Usually a set of requirements models give little hint as to the overall structure of the software design: A computable structure, called the software architecture, must be set up. Depending on machine requirements issues the developer may be forced to consider such issues before domain, or before interface requirements concerns.
By a component we understand a set of modules such that the coherence between the modules in the component set (c) is high, or higher than any other set of modules (c') overlapping with c. Usually a component is determined by either considerations of domain requirements, or considerations of machine requirements, or considerations of interface requirements.
The ``etcetera'' covers over such things as module design and code development.
By informatics we shall understand the confluence of mathematics, computer science cum programming methodology, and applications.
Informatics relate to IT as biology relates to bio technology, that is ``tangentially''. One embodies the other. Informatics is basically a science and a practice which builds on mathematics (linguistics and philosophy). IT builds on the natural sciences.
IT is characterised by material issues of quantity: Faster, smaller volume, cheaper, large capacity, etc. Informatics can be characterised by issues of intellectual quality: Better ``fit'', more pleasing, elegant, etc.
IT, in a sense, represents a universe of material quantity. Informatics one of intellectual quality.
To `Transportation & Logistics' we ``count'' the sets of such enterprises as railway (bus, shipping, air) infrastructure owners (eg., the railway net (resp. roadnet, airport, and harbour) owners), railway (bus terminal and road net [toll way etc.], harbour and canal, airport and air traffic control) infrastructure operators (operating the nets: Lines and stations, signalling, etc., resp. bus deports and toll ways, harbours and canals, airport), train (bus, shipping, airport and air traffic) service providers (on shared transport nets), regulatory agencies, clients (ie., passengers, companies wishing to transport freight, etc.), providers of services to the above (equipment manufacturers, net (bus depot and road net, harbour and canal, aiport and air traffic control center) construction firms, travel agencies, etc.), and especially logistics firms (which offer services to freight customers: Arranging composite transfer of goods via combinations of rail (freight train), road (truck), ship (boat), and air (cargo).
To describe `Transportation & Logistics' means to describe all those enterprises, agencies, clients, etc., as well as their interaction.
Just exemplifying for railways we briefly mention the entities, functions and behaviours of the specific domain: (1) The net (lines and stations), (2) the trains, (3) the net operations (signalling, stations, etc.), (4) the despatch: monitoring and control of trains, (5) the handling of passengers and freight, (6) the planning, development and phasing-in of new lines and stations and the phasing out of lines and stations, of new train services, (7) the scheduling and allocation of: (7.i) time-tables, (7.ii) rostering of train crews, (7.iii) the composition and decomposition of trains, (7.iv) train maintenance, etc., etc.,
Similar outlines can be given for bus transport, for shipping, and for air transport.
The above constituted but a capsule view of what need be modelled when creating a domain theory for Transportation & Logistics.
See Detailed Enumeration of Issues to be Modelled below for a more detailed enumeration of phenomena of the domain to be modelled.
The challenge consist in creating a believable, ie., a generally accepted, coherent, commensurate, consistent and relative complete set of models of the `Transport & Logistics' domain, including all the relevant kinds of documents mentioned earlier, and including both formal specifications and domain theories.
Believability means that a significant fraction of the conventional transport and logistics professionals point to the `Transport & Logistics' domain models (etc.) as the basis for their daily work.
This means that a significant fraction of possible re-engineerings of the `Transport & Logistics' domain business processes are based on, ie., refer to the models, and adhere to these. Adherence means that any business process re-engineering leaves the theory unchaanged, that is: That theorems that held before the business process re-engineering also holds afterwards, or, where a business process re-engineering has uncovered misunderstandings or shortcomings of the underlying models, these are corrected, respectively further sharpened.
It is to be expected that several different kinds of models together ``portray'' the domain, and, where these models are expr4ssed in different formalisms, that these different models are carefully and convincingly related (``integrated'', ``unified'').
We refer to ``Grand Challenge'' Unifying Theories of Formal Methods - Integrating Formal Methods for a discussion of the issues of integration cum unification.
The challenge can either be formulated as one which only focuses on one of the modal transports:
Or the challenge can be one which focuses on
Or the challenge can be all or several of these.
To appreciate the complexity and concerns of multi-modal transportation one might just take a brief look at
| 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 challenge. |
| See The EU Transport RTD Programme's Transport Research Projects: Rail Transport |
| The current author could wish for a better characterisations than the one below. |
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 description.
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.
There are different levels of scheduling & allocation: from strategic via tactical to operational concerns.
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.
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.
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.
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.
A domain description models the whereabouts of rolling stock, statically and dynamically, and the composition and decomposition of trains: sets of waggons etc.
| To be written |
| To be written |
| To be written |
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.
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.
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 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:
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 - 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!
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.
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.
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 interface with consultants and infrastructure owners and operators.
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, 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.
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 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.)
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.
| To be written |
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.).
| We leave a characterisation to the imagination of the reader. |
| See The EU Transport RTD Programme's Transport Research Projects: Urban Transport |
| and its Road Transport home pages. |
| We leave a further characterisation to the imagination of the reader. |
| See The EU Transport RTD Programme's Transport Research Projects: Waterborne Transport |
| We leave a further characterisation to the imagination of the reader. |
| See The EU Transport RTD Programme's Transport Research Projects: Air Transport |
| To come |
Meanwhile you may wish to browse some of:
| To be written |
Meanwhile you may wish to browse some of our own ``rumblings'' in the area:
| To be written |
| To be written |
Let us comment:
Inherent in these ``Grand Challenges'' is, that one reaches a state - 10-20 (ten-twenty) years hence - where one can say: We have basically achieved the ``Grand Challenge'' -- aside from a number of undoubtedly interesting, and, in themselves, difficult, challenging, but not ``grand challenging'', issues, we, the scientific/technological (Transport X plus computing science etc.) community think that ``we have put a man on the moon''.
But what can we achieve in lesser time ? Surely somewhat demonstrable must be achievable in a framework of, for example, five (5) years ? Yes, I believe so, and that ``something'' I will call a ``Smaller Challenge'':
The ``diversity'' is the crucial issue here: Examples of teo diverse software sub-systems could be: (1) Real-time, safety-critical software for the monitoring and control of train traffic, and (2) a passenger ticket reservation and ticketing sub-system. Now why would they need to interact ? Well, perhaps it is a bit construed, but at least it is illustrative: The passenger when being ticketed may ask: Are we on time ? Or: What is the cause of the delay ?
The current author of this document presently (ie., September 15, 2003) thinks that it will take at least 10 years, probably more realistically up towards 20 years, before a reasonably ``complete'' domain theory for `Transportation & Logistics' will have been both established and generally accepted.
The current author of this document presently (ie., September 15, 2003) expects the following to hold for at least an initial 4-5 years of a ``Grandest Challenge'' (or a ``Grand Challenge'') [or a ``Smaller Challenge''] project:
| To be written |
| To be written |
The current author of the present document has the following, somewhat provocative, opinions:
It may be that some of the 5-10-20 worldwide groups are locally funded. No comments.
Otherwise it should be curtailed.
And: If they are worth anything, that ``worth'' should be of such a nature, and so obvious, that local, say transport industry, and/or regional, public, say EU, funding agencies wishes to fund - ie., by themselves ought offer to ``ride the band-waggon'', to be associated with an emerging success story.
/home/db/colognet/web/transport.tex
This document was generated using the LaTeX2HTML translator Version 2K.1beta (1.47)
Copyright © 1993, 1994, 1995, 1996,
Nikos Drakos,
Computer Based Learning Unit, University of Leeds.
Copyright © 1997, 1998, 1999,
Ross Moore,
Mathematics Department, Macquarie University, Sydney.
The command line arguments were:
latex2html -split 0 -toc_depth 6 transport
The translation was initiated by on 2003-09-15