|
BESPOKE SIMULATION
Software has been employed by the railways
industry, and in traction engineering in particular, since mainframes with paper
tape and card readers became commonplace in the late 1960's. At that time
Universities and large organizations monopolised the scare computing resources.
While companies were writing their own COBOL business programs, academics and
students applied the scientific based FORTRAN language to research problems. This
provided the opportunity to replace restrictive analogue simulations with digital
computer simulations of greater complexity. Circuit analysis and behavioural
modelling on a large scale was possible - DC motors, chopper circuits, thyristors.
Simulation first supported theoretical analysis, and then extended it beyond what
was analytically feasible.
Coding was largely a process of trial and error, often with poor or no structure.
However, undoubted excitement and motivation was born on the vision of ever
increasing computing capacity, giving rise to complex system models. The globally
renowned railway network simulator from the Traction Systems Group at Birmingham
University evolved at this time. This allowed new rail systems to be designed
optimally, while existing systems could be evaluated prior to renewals. Headway
and stopping distance adjustments allowed train scheduling optimisation. Over
years sets of traction specific sub-systems models have been developed, know as Cecube Components, that allow
sophisticated models to be quickly assembled using C, VB or FORTRAN. These
reusable code modules are structured with defined i/o, allowing high order systems
to be divided into low order sub-systems.
An example of a relatively modern bespoke braking system model for a hypothetical
EMU can be downloaded for evaluation (suitable for any Windows OS).
To execute, unzip contents of download into an
empty folder and double click on the file Brake_Simulator.exe. Instructions to run
the simulator can be found in the Read_Me file.
RAILWAY EMBEDDED SOFTWARE -
SIL2 LIFE CYCLE CONUNDRUM
Increasing use of railway embedded software
is evident in recent traction and signalling equipment builds. Embedded software
enables extra complexity and functionality to be built in without significant
hardware cost. Functions previously implemented in analogue electronics are now in
firmware on processor based digital electronic modules. However, software
development is neither quick or cheap. Safety-critical components of the code
demand rigorous conformity to an appropriate software safety integrity level
(SSIL). The overriding European standard is IEC61508 (7 parts) -
Functional safety of Electrical / Electronic / Programmable Electronic
safety-related Systems. Software is dealt with in part 3, however, EN50128
(Software for Railway Control and Protection Systems) is the CENELEC sector
specific standard dealing with software. EN50128 states that it took guidance from
earlier work included within IEC61508, so there is considerable similarity between
EN50128 and IEC61508, Part 3. In turn, Part 3 of IEC61508 makes frequent reference
to the general requirements in Part 1 of that standard.
One important difference between the standards is that EN50128 explicitly
describes SSIL, whereas IEC61508 defines safety integrity levels (SIL) for the
equipments under control, thus encompassing both hardware and software. EN50128 is
therefore software specific unlike IEC61508, but this is a predictable result of
railway sector interpretation of the standard. EN50128 also identifies
requirements, life cycle issues and documentation. It gives detailed descriptions
of objectives, input documents, output documents and software requirements
specification, as well as architecture, design and implementation, verification
and testing. It covers software/hardware integration, software validation, quality
assurance and maintenance. It also addresses the concept of software configured by
application data (e.g. "table driven software"). In Annex A, which is normative,
it provides criteria for the selection of techniques and measures, depending on
the SSIL. In Annex B, which is informative, it gives descriptions of the
techniques identified in Annex A.
Unfortunately rolling stock fleets equipped with embedded software built prior to
the inception of these standards (~1999) will be in service for many years yet.
However, aspects of current practice would have been incorporated into the
software quality assurance measures of legacy system. Unfortunately the CENELEC
standards were written for and apply to the development of new systems. For any
established system the standards expect that a full railway safety case already
exists. Any subsequent upgrade of an established system is covered by the
"modification or retrofit" sections of the standard. The terminology used demands
an "appropriate" update of the safety case.
In cases where a system is manufactured and commissioned prior to the adoption of
the standards then there is no railway safety case to update. In this situation it
is not possible to follow the life cycle models of IEC61508 and EN50128, and it
becomes necessary to build an "appropriate" safety case. The requirements of the
appropriate safety case will be determined by the extent of the upgrade or
modification and that left unchanged. The upgrade implementation phases should
follow the principles given in the standards, even where this requires the
manufacturer adopting further recognized procedures demanded by the standards. To
create an appropriate safety case, evidence of HR (highly recommended) procedures
identified by EN50128 is necessary. These are submitted to an approval process
specifically instigated to assess the upgrade of legacy systems. The HR procedures
deemed necessary depends on the SSIL required. However, railway safety cases on
new rolling stock traction software are accepted at level 2 (SIL2) with a
strong supporting safety case, whereas software for a signalling system would be
expected to achieve SIL4. For retrofit traction systems even level 1 may be
appropriate in some cases, where a rigorous supporting fault tree analysis
demonstrates that the top-level failure rate of the equipment is acceptable.
|
|
