Systems Engineering in Different Domains: The Rail Domain. Bristol Local Group 27th January 2010 Bruce Elliott

Transcription

1 Systems Engineering in Different Domains: The Rail Domain Bristol Local Group 27th January 2010 Bruce Elliott 1

2 Peculiarity 1: Railways are highly-interconnected networks 2

3 Peculiarity 1: Corollaries for SE We are always in the maintenance phase Systems architecture is an input rather than an output Usually codified implicitly in standards There will be parallel changes to take account of 3

4 Did Julius Caesar write this? Technical specification for interoperability relating to the infrastructure subsystem of the trans-european highspeed rail system (2002/732/EC) Track gauge the distance between the rails (gauge) shall be set at the reference standard value of mm 4

5 Peculiarity 2: We have to keep railways going as we change them Imagine that the Royal Navy was replacing an aircraft carrier but had to convert the old one to the new one by replacing components every weekend and putting the vessel back to sea every Monday Corollary for SE The design problem is always 4D: the fourth dimension is the migration path from old to new systems 5

6 Peculiarity 3: Railways seldom push the envelope The logic of competition is that A new airliner must carry more passengers, use less fuel than its predecessors A new fighter must turn faster, wreak more havoc This is the exception rather than the rule in rail In rail, the pressure is to do what has been done before more cheaply, safely and reliably The UK government issues high-level statements of what it wants from the country s railways. The current statement sets output requirements under only three headings safety, reliability and capacity and associates them with a target of doing so with cost efficiency gains of 31% over 6 years. Department for Transport (2007) "Delivering a Sustainable Railway". 6

7 Peculiarities 1 and 3: Corollaries for SE The requirements phase is dominated by constraints rather than objectives 7

8 Peculiarity 4: Railway engineering has evolved separately 1825 Stockton and Darlington Railway Richmond VA Electric Streetcar 1964 Shinkansen s First mechanical signals Interlockings required by law in UK s Birth of SE 1991 INCOSE formed (as NCOSE) 8

9 Peculiarity 4: Corollaries for SE Some of the functions claimed by SE are already performed by: Project managers Project engineers Architects There are existing processes in place that overlap classical SE Technical Approval in the Design of Track Infrastructure, RT/CE/P/ issue 1 Prior to submitting designs to Network Rail for acceptance, the Contractor s Engineering Manager shall arrange to carry out interdisciplinary checks. INCOSE SE Handbook, version 2a Technical reviews are essential to ensure that the system being developed will meet requirements, and that the requirements are understood by the development team. [ ]. Typical reviews include: 9

10 Sectors are not uniform RIBA culture ICE culture IMechE culture IEE culture MIL-STD culture Devt. Standalone products Complex interfaces Maint.. Network in continual service Many simple interfaces 10

11 Case Study Replace all points and crossings within the blue lines To current standards Unless otherwise agreed All work to be completed within a 54 hour period 11

12 SE in Rail 1 Reporter: What do you think about Western Civilization? Railway Systems Engineering Mohandas Karamchand Gandhi: I think it would be a good idea. Bruce Elliott 12

13 SE in Rail 2 Issue We are always in the maintenance phase Current practice Initiate surveys Put in places processes for managing standards Systems and derogations architecture is an Put in place liaison input rather than between project and an output asset owner Usually codified implicitly in standards There will be parallel changes to take account of Good Practice (?) Improve asset knowledge Store requirements, assumptions and information about the system environment in a repository and link the items Link project and asset owner configuration management systems 13

14 SE in Rail 3 Issue Current practice Good Practice (?) The design Create and maintain Integrate migration problem is always migration path in parallel path with design of 4 dimensional: the with design of final final system fourth dimension is system the migration path from old to new systems 14

15 SE in Rail 4 Issue Current practice The requirements Train designers to work phase is dominatedwithin these constraints by constraints rather than objectives Good Practice (?) Store requirements, assumptions and information about the system environment in a repository and link the items 15

16 SE in Rail 5 Issue Current practice Some SE functions? are already covered by existing roles and processes Good Practice (?) Negotiate boundaries of the SE discipline with the natives 16

17 SE in Rail 6 Issue Current practice Good Practice (?) There may be many simple interfaces Treat some interfaces in As current practice system space and others in project space (for instance by design interface agreements) 17

18 Project and system space Early Start Duration Early Finish Task Name Late Start Early Start Duration Slack Late Finish Early Finish Early Start Duration Task Name Late Start Slack Early Finish Task Name Late Finish Early Start Duration Early Finish Late Start Slack Late Finish Task Name Late Start Slack Late Finish 18

19 Thank you for listening 19