Consideration of interoperability in the deployment of systems engineering processes Clémentine Cornu*, Vincent Chapurlat**, Jean-Marc Quiot*, Louis Fabre* and François Irigoin*** * Eurocopter, ETZCR, Aéroport International Marseille Provence 13725 Marignane Cedex - France (e-mail: {Clementine.Cornu ; Jean-Marc.Quiot ; Louis.Fabre}@eurocopter.com) ** LGI2P - Site EERIE de l'EMA, Parc Scientifique George Besse 30035 Nîmes cedex 1 - France (e-mail:
[email protected]) *** Mines ParisTech – CRI, 35 rue Saint Honoré, 77305 Fontainebleau Cedex - France (e-mail: Franç
[email protected]) Abstract: the design of a complex technical product or “system of interest" (SOI) implies various stakeholders with distinct points of view and stakes. It requires collaboration between many disciplines, cultures, and different kinds of resources at each level of a single company and often of various companies. To carry through this activity and satisfy all the stakeholders’ requirements and expectations, the Systems Engineering (SE) approach acts as a methodological and normalized framework proposing a structured “System Used To Design” (SUTD) composed of standardized collaborative processes. As SE implies many interactions, interoperability represents a major stake especially in the case of large programs or projects for both SOI and SUTD. The purpose of this paper is to present an approach for deploying SE processes within a company taking into consideration the interoperability of the entities involved in these processes. One step of this approach is the appraisal of the interoperability of these entities prior to collaboration. For this, an interoperability maturity model has been developed and is introduced in this paper. Keywords: Systems Engineering, Interoperability, Process, Aerospace Engineering, Interdisciplinary design, Design Systems
1. INTRODUCTION A System Of Interest (SOI) can be formally defined as “the system whose life cycle is under consideration” (ISO 2008). A company has to design and to produce different SOIs (products or services) meeting customer’s and stakeholders’ expectations. To achieve this goal, various systems are required during the SOI lifecycle. Among them, the “System Used To Design” (SUTD) plays an essential role. Indeed the SUTD enables the design, the optimization, the verification and the validation of the required SOI. Thus, it involves, in more or less large programs and projects, a set of collaborating actors, disciplines, tools, methods, etc. Systems Engineering (SE) approach is considered today as an efficient methodological and interdisciplinary approach for defining an efficient model of SUTD (ISO 2008, INCOSE 2010). It promotes particularly a collaborative work among project stakeholders having, among other things, different cultures, stakes, organisations, business activities and rules. It guides, structures, and standardizes when possible a set of collaborative processes having to be deployed and monitored within the company all along the SOI design phase. Thus, in order to apply the SE approach, the company has to define and to deploy SE processes tailored to its organisation and needs. Among the numerous benefits, let us notice that the use of processes makes the organization much less sensitive to the different changes happening throughout the company’s
life (staff turnover, organizational changes, etc.). Moreover, it makes the management and the continuous improvement easier. Furthermore, the processes advocated by the SE enable a significant improvement of the control of cost and schedule of project and development activities (INCOSE 2010). However, being able to deploy efficiently SE processes depends on many factors: human, technical, environmental, strategic, regulatory, societal, etc. This research work focuses on the interoperability factor. Enterprise interoperability can be defined as “ability of enterprises and entities within those enterprises to communicate and interact effectively” (ISO 2010). This article focuses then on the required interaction relationships existing between the entities involved in a SE process sharing a same goal and working together. It proposes to characterize and to define how to evaluate, as much as possible, the impact of this interoperability on the processes deployment and operational life in order to anticipate problems (relative to compatibility, to collaborative work, to data sharing, etc.) prior to processes deployment. The principle of a SE processes deployment approach considering interoperability is presented and illustrated with the case of a helicopter designer and manufacturer. This paper is structured as follows : Section 2 introduces the subject of the deployment and its key factors of success ; and Section 3 presents the different stages of the proposed approach for deploying SE processes.
2. DEPLOYMENT OVERVIEW: SUBJECTS AND KEY SUCCESS FACTORS 2.1 Subjects of the deployment: SE processes This research work aims to formalize and validate in situ an approach for deploying SE processes within a company and then to design a dedicated system to manage this deployment. Even if the will to deploy SE processes exists, a preliminary study is required to know what has to be deployed (content of processes, sequencing, etc.). Documents addressing SE are numerous. Among them, SE handbooks like (INCOSE 2010, Shishko2007); or also norms like (ISO 2008) are certainly the most recognized in the SE field. A harmonization effort has been directed by INCOSE, since in its handbook latest version, an alignment of its processes with those proposed by (ISO 2008) is realized. Finally four categories of processes are now considered: agreement processes, organizational project-enabling processes, project processes, and technical processes. This work focuses only on technical processes and the Stakeholder Requirements Definition Process has been chosen as an example to illustrate our point. This process is traditionally the first process to be deployed in companies. Its mission is to identify the distinct stakeholders of the SOI, to capture their needs and then to deduce a requirements referential that the SOI has to meet. 2.3 Deployment key success factors The success of the deployment is conditioned by key factors grouped into two categories presented by (Hill 2000) and adapted to our study:
qualifier”. For instance, any lack of interoperability constitutes an unacceptable source of failures and risks for the process. On the other hand, interoperability can especially be considered as an “order winner”: if the interoperability of resources can be characterized, evaluated and maintained at a high level of maturity, the deployment and the exploitation of the efficient SUTD will be facilitated. 3. PROPOSED APPROACH FOR DEPLOYING SE PROCESSES The purpose here is to introduce an approach to deploy SE processes within a company. This SE processes will constitute the SUTD of the new SOIs of the company. To structure and to describe intuitively the various phases of the SUTD design project, a classic PDCA (“Plan Do Check Act”) cycle has been chosen. The design project requires two complementary fields: 1) the enterprise modelling field that is crucial here for the process modelling tools, frameworks and methodologies it proposes and 2) the SE field for its rigorous methodological approach. It also requires the definition of teams in charge of the deployment (global and specific to each SE process). The goal is then to define the team mission and objectives, the members’ roles and the resources they can use. The approach phases are detailed in the following. 3.1 First phase: “Plan” It includes various analyses necessary to design the SUTD, i.e. the coherent set of SE processes (see Fig. 1).
1) “Order qualifiers”: factors needed to make the future entities involved in a process accept it. These factors condition the possibility to deploy or not the process. Here are some examples of "order qualifiers": -
Beginning and justification of the approach for setting up processes by the company management; Satisfactory level of understanding of the approach by the various actors involved; Technical and organizational validity of the proposed process; Potential or proven interoperability of actors, teams, means and tools.
2) “Order winners”: factors guaranteeing that the process deployment is realized efficiently and the exploitation of this process actually generates a competitive advantage. Here are some examples of "order winners": -
Good listening and consideration of the various process stakeholders’ expectations; - Anticipation of difficulties thanks to deep studies; - Presence of experts in processes deployment; - Real, evaluated or improved interoperability of actors, teams, means, and tools. Therefore, on one hand, the interoperability of the different entities involved in a process can be considered as an “order
Fig. 1 - Overview of the phase "Plan"
Sub-phase 1 – Modelling of the ideal SUTD Considering the SUTD entirely, the team in charge of the global deployment defines what would be ideally the SE processes composing the SUTD. The goal is to provide an ideal model describing the company’s vision of what must be the appropriate organization to be developed and what resources are required for optimal functioning of the processes to deploy. The scope is therefore limited: there is no point here of modelling the entire company organisation or being influenced by its current business structure/organisation. To specify the SUTD, we suggest using the sequence of activities described by SE for the creation of a system. Firstly, SE processes to deploy and their interactions must be specified. For this the set of documents relating to SE is used as a basis for this work. For instance, in the context of a helicopter manufacturer, three sources of documents addressing SE and defining SE processes are used. Let us cite standardisation documents (ISO 2008, IEEE 2005, ISO 2003, EIA 2003, DoD 1994), documents providing advice and feedbacks (INCOSE 2010, USDT 2009, MEINADIER 2009, and Shishko 2007) and aerospace and aeronautics specific documents (ECSS 2009, BNAE 2005, BNAE 1999). However, it is important to notice that they often address the process level, but much more rarely the activity or tasks levels. In addition, some themes are still not addressed even in a generic way. For example, identification of processes stakeholders, their roles and responsibilities, the outcomes and enablers at the activity and task levels are ignored. Thus, it remains difficult to apply directly the proposed vision of SE processes provided and argued in these documents. In addition, the targeted ideal model must take into account constraints that cannot be ignored such as those related to aircraft certification/qualification. However, these constraints are rarely present in SE standards, even in those specific to aeronautics. Last, the deployment team must adapt and formalise the SE processes. The concerned stakeholders are then identified in order to capture their needs and expectations. Once these needs are translated into requirements and validated by these stakeholders, a functional architecture can be built. The formalism chosen to describe the ideal SUTD model depends of course on the company business objectives, size, skills and know-how, resources nature and type, etc. However, it has to be easily understandable by the different actors to prevent their rejection and to promote their involvement in the project. Moreover, in order to take into account the interoperability criterion when defining processes, it may be appropriate to rely on existing “interoperability frameworks” which can provide means to characterize the targeted interoperability and its good practices as defined in (IDABC 2008, ATHENA 2007, INTEROP-NoE 2007, NEHTA 2007a, UK Government 2005, IDEAS 2003). So, the functional architecture of the required SUTD is modelled by defining a global and ideal map of SE processes within the company. A process modelling language is then used to detail each process. However, this language has to be enriched taking into consideration the interoperability points seen above. This
language is currently under construction and depends on the Interoperability Maturity Model introduced in the next part. The deployment team must then propose and validate an organic architecture of the SUTD, i.e. to determine what are the theoretical entities (e.g. organisational units, actors, other companies) which carry out the various activities described in the functional architecture. This identification of entities needed to ensure the smooth operation of processes is a step that must be conducted carefully. For example, any omission of a stakeholder induces a risk of missing specific needs, particularly interoperability needs, which can have harmful direct or indirect effects on the deployment. It is suggested to start identifying the various entities in a global way and then to refine progressively the results considering the company’s specificities and business field. To illustrate our point, here is an example of entities identified involved in the Stakeholders Requirement Definition Process of a helicopter manufacturer: customers (e.g. private individual, state); subcontractors (e.g. development agencies, suppliers); regulatory bodies (e.g. EASA); users (e.g. passengers); operators (e.g. pilots); maintainers (e.g. aircraft mechanic, spare parts suppliers); support organizations; enterprise and group decision-makers; program & project managers; planning teams; design office members (e.g. scientists, subsystems engineers); society-atlarge (e.g. manufacturer, purchasing department). Sub-phase 2 – Modelling of pre-existing SUTDs Following SE principles, a company producing SOIs have necessarily defined a specific SUTD for each SOI in order to design, validate, and produce it. It is then possible that these pre-existing and dedicated SUTD (i.e. before deployment of new SE process map) no longer exists or are no longer complete in the new organization of the company. For example, if the company, because of the complexity of its products, does not create new products from the customers’ needs anymore but realizes technological innovations on its existing products, the design and development system of new technical solutions can disappear… So the deployment team must build an AS-IS model following the classical principles of enterprise modelling. This model represents either the actual pre-existing SUTDs if they still exist in the company and if the company wants to keep them as a basis; or the current organisation making new SOIs from existing SOIs. To achieve this modelling stage, many methods, languages and tools developed in the frame of enterprise modelling can be used. The purpose of this AS-IS model is to identify and represent entities (company’s departments, subcontractor, etc.) already involved in the design of SOIs and that could achieve the activities of the ideal SUTD. All the interactions between these entities must be identified. Each identified entity is then characterized and it is crucial to express all its implicit and explicit expectations when facing the pointed out SE process. Many methods and tools, which have been developed to support the capture of the needs in the context of quality improvement (compliance to ISO 9001, etc.) and in the context of SE, can be used for the identification of entities’ needs. However, they do not address in detail the interoperability point of view. As a consequence, the interoperability requirements repository developed by (Mallek et al. 2010) can be used also. The
authors propose to group interoperability requirements into three categories: compatibility, interoperation and reversibility, and then to refine them according concerns and barriers proposed in (ATHENA 2005). Thus, this classification is a way to structure the identification of entities’ needs and requirements regarding interoperability. Sub-phase 3 – Interoperability assessment of entities previously identified In the previous sub-phase, entities that could achieve the activities of the ideal SUTD have been identified. However, their interoperability has to be assessed in order to know if they are able to collaborate within the SUTD. To this end, we propose to evaluate two parameters: 1) the interoperability maturity of each entity, that is, the ability of each entity to interoperate within a given SE process and 2) the compatibility of each couple of entities having to collaborate “face to face”. As our work focuses on anticipating and preparing the deployment, that is, before any effective collaboration, we address neither the interoperation measurement nor the evaluation of the compliance with the reversibility requirements (Mallek et al. 2010). The appraisal of the ability of entities involved in the ideal SUTD to interoperate before any collaboration is as a way for the company to know whether an entity is able or not to be part of a process before any effective collaboration. Two scenarios can be considered: 1) the maturity level of the entity is sufficient and, if so, collaboration can be considered after a compatibility assessment; 2) the maturity level of the entity is insufficient, and, if so, either the company helps the entity to find the dysfunctions and to correct them (e.g. in the case of an entity which would be a part of the enterprise), or the company rejects the entity until it increases its capabilities by itself (e.g. in the case of an entity external to the enterprise). A way to assess the maturity of entities is to use a maturity model (MM). A classical MM is represented as a grid with one dimension describing the assessment criteria and the other, the levels of maturity. It enables each studied entity to graphically detect on which criteria improvements must be done to move from a given level to a more efficient one. For the assessment of entities, the following requirements concerning the MM can be expressed: 1) the MM must address the three interoperability barriers described in (ATHENA 2005) that is the organisational, conceptual and technical barriers 2) the MM can be applied to any type of entity (e.g. company, single actor, state, company’s department) and 3) the MM can be applied directly in aeronautics industry. The main existing MMs specific to interoperability (De Soria et al. 2009, Santos et al. 2008, NEHTA 2007b, Athena 2005, Tolk et al. 2003, Clark et al. 1999, C4ISR 1998) do not individually fully meet the needs expressed above. The proposed Interoperability Maturity Model is composed of two layers, four criteria and four levels (see Fig. 2). The first layer is generic and applicable to each SE technical process composing the SUTD. The second layer complements the previous layer by adding assessment factors specific to each SE process. This structure has several advantages. First, it enables to assess entities only according
to criteria relevant to processes in which they are involved reducing thus the assessment work. Then, it makes the assessment of the SUTD entities more homogenous between the various processes since the basis for the appraisal is common to all processes. Finally, in case of amelioration of the IMM, any change in the generic layer affects the evaluation of all processes in a single stroke.
Fig. 2 – Structure of the interoperability maturity model Here are the proposed criteria for appraisal: 1) Overview of the entity and its interoperability management: this concerns the capacity of the entity to introduce itself to a partner, globally and from an interoperability point of view. This overview of the entity is necessary for mutual comprehension between the partners: their stakes, constraints and current involvement in an interoperability improvement approach. In other words it allows estimating the entity's ability to formalize what it is and what it wants in order to make itself and its context better understood by its partner. Here are its sub-criteria: - Definition of the entity (e.g. scope, purpose, goal) - Constraints that the entity has to respect - Approach for improving interoperability 2) Structure of the entity: this concerns the formalisation of the structure of the entity. So it assesses the capacity of the entity to get over the organisational barrier. This allows providing a link between the organisations of the partners. Here are its sub-criteria: - Organic structure (departments, actors) - Logical structure (processes) 3) Resources needed by the entity: this concerns the capacity of the entity to list, analyse and change its resources in order to improve interoperability. So it assesses, among others, the capacity to get over the technical barrier. Here are its sub-criteria: - Material resources - Software resources - Methodological resources - Human resources - Financial resources 4) Concepts handled by the entity: this concerns the capacity of the entity to formalize and share the various concepts it uses. So it assesses the capacity to get over the conceptual barrier. Here are its sub-criteria: - Syntax - Semantics - Pragmatics Here are the four interoperability maturity levels:
1) Ignored. The entity does not anticipate its collaborations: each cooperation is managed in a different way. So, the pointed out entity seems not able to take interoperability into consideration during deployment phases. 2) Formalized. The entity corrects existing interoperability dysfunctions. From the aspect of interoperability, the entity has means to make its future collaborations go smoother. These means are formalized, standardized and fully shared within the entity. 3) Monitored. The entity fully anticipates its collaboration and has deployed means to monitor the efficiency of its collaborations. 4) Optimized. The entity, according to its interoperability monitoring, continuously improves its interoperability. From a methodological point of view, first the IMM is used by the deployment team which has to determine the level reached by each identified entity on each criterion. For this, the information required for the analysis is collected and interviews are conducted with various actors of the entity evaluated. Moreover the reference documents made available by the entity are studied. Second, entities that could participate in SUTD and have crossed the interoperability maturity threshold defined by the deployment team, are assessed a second time. At this stage the assessment is done on pairs of entities. The purpose here is to measure the compatibility of a pair of entities that would have to collaborate really within the SUTD. Unlike the maturity assessment which is performed on each entity separately and evaluates the potential interoperability of the entity, the purpose here is to evaluate the interoperability of two identified entities. To conduct this appraisal, we suggest using an adapted version of the interoperability compatibility measurement proposed in (Daclin et al. 2008). The authors propose to break down the compatibility into conceptual, technical, organisational compatibility. Each kind of compatibility is assessed according the four concerns introduced by ATHENA (business, processes, services, and data). Incompatibilities are carried forward a matrix. The deployment team can use a tailored version of this compatibility measurement. Indeed, an adaptation is needed since the levels "business", "processes", "services" and "data" are not relevant for all types of entities and may has a computer connotation. Thus, we suggest replacing them by: "entity", "process", "activity" and "data, documents and models". Sub-phase 4 – Modelling of the SUTD to deploy The deployment team builds then a TO-BE model i.e. compares the models representing the ideal SUTD and the AS-IS model representing the current organisation in order to perceive where significant gaps are and thus highlights ways of improving the current organization. The model is built to share the compromise found between the actual and the ideal theoretical organization. An action plan is defined for the deployment. If at the end of the Sub-phase 2, some activities of the ideal SUTD are still needs not “allocated” to any existing entity, the company has to collect them and to define specifications that one or several potential entities will have to honour. Finally, after a verification of the coherence of the different models (ideal, AS-IS and TO-BE), validation
scenarios allowing to validate the resulting and deployed SE processes and tests methods are defined. 3.2 Second phase: “Do” It consists in deploying the SUTD. For this purpose, it triggers the successive deployment PDCA cycles of each SE process identified to be deployed according to the action plan defined at the previous phase. The generic deployment phases to be carried out for each selected SE process are: 1. Sub-Phase "Plan”: The TO-BE model defined in Subphase 4 is then analysed and refined into an implementation model focusing now on the physical deployment of the SE process under study. The deployment team in collaboration with entities directly involved in the process realizes the following: 1) process definition, 2) assessment of risk and problems (human and technical problems, but also problems related to poor ability of the business entities to be interoperable), and 3) preparation of the deployment (action plan, corrective actions anticipating some problems identified during the previous phase, indicators for success measuring, roles and responsibilities etc.). Moreover, considering validation scenarios and verifications made in Sub-phase 4, a set of validation scenarios and tests methods are defined for the pointed out process to deploy. 2. Sub-Phase "Do": the deployment phase in which the process is implemented respecting and adapting, if necessary, the implementation model defined in previous steps. According to the implementation model, the resulting process is then validated by using different tests. 3. Sub-Phase "Check": the use phase during which the process is tested, and deviations from objectives are evaluated. 4. Sub-Phase "Act": the phase of improvement, during which malfunctions are corrected, where best practices are standardized and capitalized, and new performance targets are set. 3.3 Third phase: "Check” During this phase, the team can then first compare the deployed SUTD with the TO-BE model developed during the first stage. Second it can check the correctness of the deployment by using validation scenarios and tests techniques defined all along the design project. Third, it can also collect ideas from the users and stakeholders for improvement. Entities chosen to be part of SUTD are often assessed to check if their interoperability maturity and compatibility are still sufficient. 3.4 Fourth phase: "Act" During this phase, proposition of SUTD improvements are expressed, analysed and validated. Best practices and feedbacks are made available for future deployments. 4. CONCLUSION This paper presents a methodological approach for the deployment of SE processes within a company.
The originality of this approach is to consider that the interoperability can be seen in same time as an “order qualifier” and as an “order winner” for the deployment of SE processes and thus, has to be taken into consideration while preparing the deployment. This article particularly focuses on the phase “plan” of this approach that includes the following steps: both ideal and existing SUTD modelling, assessment of the interoperability of entities before the collaboration, and modelling of the SUTD to deploy. In the development of the topic about interoperability appraisal, the structure of a Deployment Interoperability Maturity Model is proposed. The current work in progress focuses on the development of a modelling framework and of a SUTD modelling language linked to the IMM. In same time this IMM has to be formalised, enriched with a methodological approach for compatibility measurement and checked in the real context of the company. REFERENCES ATHENA (2007), 'Deliverable D.A4.2 - Specification of Interoperability Framework and Profiles, Guidelines and Best Practices', ATHENA Project. ATHENA (2005), 'Deliverable D.A1.4.1 - Framework for the Establishment and Management Methodology', ATHENA Project. BNAE (2005), 'RG AERO 000 77 - Programme management - Guide for the management of Systems Engineering', Bureau de Normalisation de l'Aéronautique et de l'Espace. BNAE (1999), 'RG AERO 000 40 A - General recommendation for the programme management specification', Bureau de Normalisation de l'Aéronautique et de l'Espace. C4ISR (1998), 'Final Report', C4ISR Architecture Working Group. Clark, T. & Jones, R. (1999), Organisational Interoperability Maturity Model for C2, in '1999 Command and Control Research Technology Symposium. United States Naval War College, Newport'. Daclin, N.; Chen, D. & Vallespir, B. (2008), Methodology for Enterprise Interoperability, in 'Proceedings of the 17th World Congress - The International Federation of Automatic Control - Seoul, Korea, July 6-11, 2008'. De Soria, I. M.; Alonso, J.; Orue-Echevarria, L. & Vergara, M. (2009), Developing an Enterprise Collaboration Maturity Model: Research Challenges and Future Directions, in '15th International Conference on Concurrent Enterprising, Leiden, Netherlands 22 - 24 June 2009'. DoD (1994), 'MIL-STD-498, Software Development and Documentation', Department of Defense. ECSS (2009), 'ECSS-E-ST-10C - Space engineering – System engineering general requirements', European Cooperation on Space Standardization. EIA (2003), 'ANSI/EIA-632:2003 - Processes for Engineering a System', Electronic Industries Alliance. Hill, T. (2000), Manufacturing Strategy: Text and Cases. 3rd ed., Irwin McGraw-Hill. IDABC (2008), 'Draft document as basis for EIF 2.0', Interoperable Delivery of European eGovernment
Services to public Administrations, Businesses and Citizens. IDEAS (2003), 'Deliverable D 3.4, D 3.5, D 3.6 - A Gap Analysis - Required Activities in Research, Technology and Standardisation to close the RTS Gap - Roadmaps and Recommendations on RTS activities', IDEAS Project. IEEE (2005), 'IEEE 1220:2005, Standard for application and Management of the Systems Engineering Process', Institute of Electrical and Electronics Engineers. INCOSE (2010), 'Systems Engineering Handbook - A guide for system life cycle processes and activities - v3.2'. INTEROP-NoE (2007), 'Deliverable DI.3 - Enterprise Interoperability Framework and knowledge corpus Final report', INTEROP-NoE project. ISO (2010), 'ISO/DIS 11354-1 - Advanced automation technologies and their applications - Part 1: Framework for enterprise interoperability'. ISO (2008), 'ISO/IEC 15288:2008 - Systems engineering System life cycle processes'. ISO (2003), 'ISO/IEC TR 19760:2003 - Systems engineering - A guide for the application of ISO/IEC 15288'. Mallek, S.; Daclin, N. & Chapurlat, V. (2010), Towards a conceptualisation of interoperability requirements, in 'IESA 2010 - Interoperability for Enterprise Software & Applications, Coventry, 14-15 April 2010'. Meinadier, J.-P. (2009), 'Découvrir et comprendre l'ingénierie système - Version expérimentale - v3', Association Française d'Ingénierie Système. NEHTA (2007), 'Interoperability Framework v2.0', National E-Health Transition Authority Limited. NEHTA (2007), 'Interoperability Maturity Model - Version 1.0', National E-Health Transition Authority Limited. Santos, I.; Schuster, S.; Vergara, M. & Alonso, J. (2008), Assessing the Readiness for Enterprise Collaboration and Enterprise Interoperability, in '14th International Conference on Concurrent Enterprising, Lisbon, Portugal, 23 - 25 June 2008'. Shishko, R. & Chamberlain, R. (2007), 'Nasa Systems Engineering Handbook', National Aeronautics and Space Administration. Tolk, A. & Muguira, J. A. (2003), The Levels of Conceptual Interoperability Model, in '2003 Fall Simulation Interoperability Workshop, Orlando, Florida'. USDT (2009), 'Systems Engineering Guidebook for Intelligent Transportation Systems', US Department of Transportation. UK Government (2005), 'e-Government Interoperability Framework - v 6.1', Cabinet Office - e-Government Unit. Vernadat, F. (1996), Enterprise modeling and integration: principles and applications, Kluwer Academic Publishers.
