2005 UK Spring Conference
 9 to 11 May 2005 at the Swindon Marriott

Once again the Spring Conference provides the opportunity to expand your horizons with an INCOSE Tutorial.  It’s a great way to gear yourself up for the main conference sessions, but if your time is limited you can participate in a tutorial as a stand-alone activity.  Use the main conference registration form (to be found on the www.incose.org.uk website) to book your place now.  The price (£220.00 plus £38.00 VAT) per tutorial includes refreshments throughout the day, buffet lunch and course materials, provided in the comfortable surroundings of the Swindon Marriot Hotel.

This year all tutorials are full-day events as a result of the limited appeal of half-day options offered at previous conferences.  As in previous years we have a mix of old favourites and new offerings, providing both lecture room and workshop styles.  The selection includes tutorials that will help you to develop specific technical skills or explore more general areas of systems engineering competence.

A typical tutorial attracts between 10 and 15 attendees, so numbers are small enough to allow individual attention from the presenters.  All of the presenters are either accomplished lecturers / trainers, recognised experts in their field or both.  You are therefore assured of an interesting, challenging and enjoyable day. 

This year you can choose from:-

• T1. Systems Thinking

• T2. Verification and Validation of Models and Simulations

• T3. SysML and UML for Systems Engineers

• T4. A Hands on Introduction to System Dynamics

• T5. Running Market-Driven and Capability-Driven Technology Planning Workshops

If you have any queries on any of the Tutorials being offered, please contact the Tutorial Chair, Peter Lister (0121 713 4311 peter.lister@siemens.com).

Tuesday 10th May - Conference Session 1

MOD’s declared intention to move towards Network Enabled Capability (NEC) places an historic challenge the organisation and the systems professionals who will participate in its construction and maintenance. This paper will review the challenges from the perspective of the author’s position as head of the body charged with improving MOD’s ‘Capability to Integrate’, and will present latest thinking on implementing across-project architectures and assurance processes, along with key enablers in the areas of processes, tools and skills.

The Indirect Fire Precision Attack (IFPA) Assessment Phase considered a wide range of munition and technology options in order to establish an affordable capability growth route map for Indirect Fire. Each option has been subjected to analysis across all Lines Of Development (LOD), each naturally presenting differing interoperability issues. As a result of this spiral assessment campaign, the IFPA programme now proposes to bring into service new munitions for a number of legacy platforms as well as completely new loitering munition capability. The legacy systems are themselves part of an evolving capability undergoing a number of upgrades.

The MOD Architectural Framework (MODAF) will provide a rigorous way to specify systems of systems and the communications between those systems, as part of the MOD's drive towards Network Enabled Capability (NEC). MODAF is based on the US DoD Architectural Framework (DoDAF), but includes a number of changes and additions to support the MOD's processes. This presentation will detail the business requirement for MODAF and outline its current status and implementation programme. Information will also be provided on the relationship between UML and MODAF, the differences between MODAF and DoDAF and the meta data exchange approach that has been taken to achieve toolset interoperability.

MOD policy in respect of Communication / Information System (CIS) acquisition is determined by the overarching objectives of Network Enabled Capability (NEC). Interoperability (IO) between systems is absolutely fundamental to NEC. It is recognised that unless Interoperability is correctly specified the risk to successful implementation is unacceptably high.

One of the initiatives undertaken by the IA has been the formation of the Interoperability and Compliance Assurance (IOCA) team. Over the last year the Integration Authority has introduced the IOCA process to some 45 EP projects. The process is now an integral part of DPA Internal Assurance and we believe it is making an important contribution to interoperability risk reduction.

Traditionally earth observation satellite missions have been conceived and designed stand-alone. However there are exciting opportunities for applications combining data from more than one mission, and now interoperability between missions is appearing in customer requirements. Interoperability is key to supporting aspects of the EC programme on Global Monitoring for Environment and Security (GMES). In Summary the paper will address:

1. What does the user want to achieve (and is interoperability the answer)
2. What are the operational concepts that are impacted by interoperability

Mullard Space Science Laboratory, University College London, has been involved in providing space instrumentation for the scientific community for over 30 years. Over that time we have developed a practical, streamlined systems engineering process for small, highly skilled teams working in a university environment. Such developments are highly constrained in terms of schedule (launch delays are generally unacceptable), cost (research council funding is extremely tight) and performance (only internationally competitive capability will secure a launch opportunity). Using practical examples we will outline how we continue to provide high quality, reliable solutions within the stringent demands of the space agencies.

Complexity in automotive systems has increased dramatically over the last decade, even though the formal systems engineering processes used are arguably the least mature of those in the transportation sector. Interoperability is focused on three main axes:

• the ability to accommodate legacy functions and features from previous automotive models
• the ability to apply functions and features cross-car line
• the ability to communicate functions and features with Tier 1 suppliers

The combination of these three axes places exacting demands on requirements and architecture design in the systems engineering process for this sector. This paper illustrates key issues and discusses possible approaches to pragmatic solutions.

Farming is becoming an increasingly technology-dependent industry. The recent availability of cheap global positioning systems has revolutionised farming possibilities, enabling farmers to make decisions at the level of position within a field, rather than making decisions for a field as a whole. With the introduction of any new technologies there are potential problems, but with an average age of 58 in the UK and finding themselves ‘systems integrators’ by default rather than through choice or aptitude, farmers have been predictably reluctant to embrace change. This reluctance has been reinforced by farmers’ past experiences of farm machinery manufacturers ‘overselling’ early technologies before the market was ready for them.

University College London has conducted a three-year research project investigating the supply-chain issues associated with new technology introduction, including the conditions necessary to ensure that a new system is easily integrated into its operating environment. 64 interviews were conducted with representatives of 30 different companies in the farming and pharmaceutical industries. This paper explores technology introduction in the farming industry and explains how the authors have helped the farming community to ensure more successful integration of advanced technologies in the future.

This paper will review the experiences of a Systems Engineer and a Human Factors Consultant, who worked on a Train Detection project in 2003/2004, part of the West Coast Main Line upgrade. The project involved the further development of a recently introduced Train Detection system (Alcatel AzLM Axle Counters). Safety features previously provided by more established train detection methods were removed, & more reliance was placed on human processes. The System development process revolved around Human Factors (HF) considerations: this paper will consider the decisions of technology based against HF techniques.

In this paper, I use the setup of INCOSE UK as a case study ‘infrastructure project’, an example of a ‘peopled system’. To begin with I show the ad-hoc developments in the typical formation stages of an INCOSE chapter, and point out the relative immaturity of the processes from a systems engineering point of view. Then I look at how we made the Chapter more self-sustaining, by a strategic overhaul of the ‘system’ using SE principles:

All models are approximations to the truth. Models of a theory-based process supported by field data can be validated using well-known statistical models. More complex mathematical models built for dynamics and control purposes can be validated by simulation or by theoretical procedures that validate their internal coherence. But what about the conceptual-cum-mathematical models used by systems engineers to design systems through a life-cycle to satisfy multiple requirements, operational contexts, and stakeholders? Do under-performing over-budget systems, let alone disasters, stem partly from inadequate models based on insupportable assumptions and omissions?

Objective of the paper is to provide an insight into some advanced simulation and modelling being applied which addresses interoperability between different transportation modes (road, rail, pedestrian) and to identify common issues in advanced simulation and modelling which may apply in other industries. This paper will include case studies (which are always useful)

The application of various software modelling packages in the transportation field has been commonplace for decades. In response to the need to find solutions to ever more challenging transportation problems, brought about by increased network congestion and constrained infrastructure solutions, the range and complexity of available software has also increased significantly. Focussing on the highways sector, modelling of transport networks is now undertaken at various scales, from analysis of a single junction/intersection to regional or national study areas. The use of micro-simulation techniques with sophisticated, interactive graphical representations of vehicles travelling through the network is becoming more popular, as is the use of complex multi-modal models that forecast transport mode, route and journey characteristics. However, recent 'lessons learned' show that these new modelling techniques have various shortcomings, particularly in relation to the effects of data accuracy at the input stage, and so cannot always be used as a reliable substitute for more 'traditional' modelling methods.

This paper will investigate the mapping between UML 2.0, SysML, and MoDAF, and the model-driven approach to architectural frameworks, as well as the RFI for MAF. It will concentrate on how the improvements brought about by SysML and UML 2.0 enable even better support of MoDAF. We will also look at the mapping between the views in a SysML modelling context, how they build on each other, and how together they form a dynamic evolutionary environment providing traceability and consistency. In this environment, performance requirements can be verified, simulations run, and additional report views can be generated based on an underlying consistent database.

The interfaces within large scale organisations are distinctly different from those existing between organisations. With differing emphasis on structure, hierarchy and behavioural expectations, the management of all interfaces needs to be approached with a different set of tools to those employed with more conventional partnerships or customer/supplier relationships. This paper profiles the categorisation of these 'Intrafaces'; and the types of pressures which drive the problem and solution space for each. By explicitly recognising the soft system tensions brought about by simplistic metric driven performance management, a path is outlined to the better understanding and management of Intrafaces. Finally the management of all such Intraface types is brought together in a single methodology which encompasses the cross connections and ensures a smooth orthogonal approach is adopted.

The single market concept has the objective of achieving economic and social cohesion from a base of regional and national disparities within the European Union. Interoperability of national infrastructure networks has emerged as a key factor for the coherent planning of community territory. As the lead engineer for the high-speed railway energy subsystem with a Notified Body, the author will explain the verification process and will consider how this creates an opportunity for risk reduction and substantial savings to be made if constituents and subsystems are developed using systems engineering thinking.

Interoperability within the railway network is one of the aspirations of the European Community. In 2002 the European Association for Railway Interoperability (AEIF) published six Technical Specifications for Interoperability (TSIs) covering Rolling Stock; Maintenance; Infrastructure; Energy; Signalling and Operations. As Assessment Coordinator for a UK Notified Body, the author will present a case study and will identify some of the tools and processes that have been assimilated to produce a multi-levelled and systems orientated approach to the assessment process along with some of the lessons learnt in this exciting new area.

Setting New Boundaries - applying UML to railway standards,  Richard Barrow,  RSSB

The presentation describes how UML has been used to improve the quality of standards definition particularly where system and organisational interfaces need to be identified. It illustrates how operational and system boundaries are identified to support the UK application of ERTMS. It will describe the profile the RSSB is developing, to enable them to model various roles within the operational railway interfaces.

Interoperability between multiple systems often referred to as Systems of Systems (SoS), is a key aim for many different types of organizations. For example, the new Department of Homeland Security in the U.S. is creating an organization that brings together many different services: CIA, FBI, police, fire service, etc., who today each have their own systems. In the defence world, you hear about ‘network-centric warfare’. This is interoperability not just across the different defence forces of one nation, but across multinational boundaries. In order to achieve interoperability we need to design systems with it in mind. A key enabler to this is having a common way to specify the architecture of systems and their interfaces. Architecture frameworks like DoDAF (Department of Defense Architecture Framework) provide this ‘common language’. This presentation will look at the benefits of adopting a requirements-driven approach to the specification of systems using an architecture framework.

Modeling requirements with the Unified Modeling Language (UML) can be confusing for both first time and experienced systems engineers. Often this is due to inexperience with UML, or a reliance on object-oriented techniques, where it is necessary to identify objects as the starting point for evaluating a potential system. When modeling requirements, however, this is normally the “pre-object” stage, where identifying potential objects can mean defining the solution rather than defining the requirements, or even prior to this, when defining the problem for which requirements for a system may be created. The techniques described in this paper focus on the UML/SysML diagrams that do not require objects, and are therefore better suited to this early part of the systems engineering lifecycle. They have been successfully used on projects in areas as diverse as transportation and defense. In addition to expressing the requirements in a pure form, they help to identify system interaction, potential interfaces and the characteristics of these interfaces, and algorithms and equations that may be used by the system.

Discussions of system engineering methodologies often assume that the engineers designing a system have substantial freedom of choice in determining how the system will be built – requirements are driven down from system goals to subsystem and equipment specifications. When a project aims to upgrade an existing system, or when interoperability requirements constrain the choice of components, subsystems or interfaces, this degree of freedom is not available to the system engineering team – constraints on specifications.

Based on our experiences of large transportation system projects in Europe and Asia, we discuss some of the challenges that these constraints pose for system engineering methods and management processes. We discuss some approaches to the problems of requirements management and the definition of system engineering work packages, and highlight some principles that we have found useful in meeting these challenges.