System of Systems architecture in ESA s Concurrent Design Facility SECESA October 2010

Transcription

1 System of Systems architecture in ESA s Concurrent Design Facility SECESA October 2010 R. A. C. Schonenborg Schonenborg Space Engineering B.V. for ESA (*) T. Bieler ESA-ESTEC A. Matthyssen JAQAR Space Engineering B.V. for ESA (*) M. Fijneman J-CDS B.V. for ESA (*) *Through a technical support contract ABSTRACT Since 2008 ESA s Concurrent Design facility (CDF) embarks on the conduct of System of Systems (SoS) studies in a concurrent way. Systems of Systems should be distinguished from large but monolithic systems by the independence of their elements, their evolutionary nature, emergent behaviours, and a geographic extent that limits the interaction of their elements to information exchange only [1]. A System of Systems is service and end-user oriented and Systems of systems are currently investigated predominantly in the defence sector. Therefore the most advanced architecture frameworks that are used to model Systems of Systems (e.g. MODAF, NAF, DODAF) originate from this sector. This paper describes the use of ESA CDF and Concurrent Design in general for System of Systems Architecture activities. The paper describes the CDF SoS architecture process, team, tools and activity examples. Architecture Process The objective of a CDF-carried-out SoS activity is to create an architecture of coupled systems that fulfils initially defined, but possibly during the study modified, requirements in a short timeframe and in a concurrent manner. The latter is realised by combining the CDF s concurrent design approach with the application of The Open Group Architecture Framework (TOGAF) Architecture Development Model (ADM) and an architectural framework for modelling such as e.g. the NATO Architectural Framework (NAF). TOGAF s ADM comprises of eight phases of which the first three to four are most applicable to the level of detail of CDF SoS activities as they are currently being carried out. Phase A, the Architecture Vision, Phase B, Business Architecture, Phase C, System Architectures, Phase D, Technology Architecture. In addition, following Phases D, E and F could be conducted if needed. In addition to these phases, the analysis, adaptation and verification of requirements is performed, in order to optimise the result and to maximise the fulfilment of requirements. During continuous circulation through the ADM and through its individual phases, the architectural solution from the service, operational, systems and technology perspective is generated, as well as the identification and analyses of gaps additional opportunities and solutions. Team A CDF SoS team is different from a traditional System Design activity team. An architecture activity can include several types of teams consisting of different types of experts e.g. policy makers, decision makers, service providers, subsystem experts and technology experts. In general a team consists of Team Leader, Architect, SoS manager, Watchkeepers, Experts and the customer. Tools Dedicated hardware and software tools are being used to; provide system inputs by dedicated specialists, create the various architectural representations and evaluate the various architectural solutions. Coupling between these tools provides a smooth circulation of information between the various team members that participate to the study. BACKGROUND The ESA Concurrent Design Facility (CDF) has investigated and implemeted user-focused-service-design, to address programme objectives that require the exploitation of disparate space and ground systems acting as a System of Systems (SoS). Such complex mission architectures will further exploit the benefits of space systems, for research, e.g. Space

2 Exploration, or for operational use, providing new services and integrated applications, e.g. GMES, Space Situation Awareness and others. Systems of Systems Systems of Systems should be distinguished from large but monolithic systems by the independence of their elements, their evolutionary nature, emergent behaviours, and a geographic extent that limits the interaction of their elements to information exchange [1]. A System of Systems is a service and end-user oriented architecture. Systems of systems are currently investigated predominantly in the defence sector. Therefore the most advanced architecture frameworks (e.g. MODAF, NAF, DODAF) originate from the defence sector. This type of SoS addresses two fundamental aspects of emerging and future programmes, namely: the integration (and interoperability) of the existing ground and space assets of Europe with each other and with external services the move from a product oriented system design to a service oriented design, focussing on the requirements from end-users of different areas, such as civil security, disaster management and environment. Until now a few initial System of Systems (SoS) architecture activities have been performed applying some proven concepts and infrastructure using in-house and commercial tools, which are constantly consolidated. Tools and models were initially retrieved and adapted from traditional space mission design environment such as the Integrated Design Model (IDM). The resulting Integrated Architecture Model (IAM) supports the interlink between different domains, e.g. data exchange, assets interfacing as well as key parameter evaluation, like cost, risk or programmatics. The IAM uses The Open Group Architecture Framework Architecture Development Method (TOGAF-ADM). CONCURRENT DESIGN APPROACH FOR SYSTEMS OF SYSTEMS Based on the experience of more than a decade with over 100 concurrent activities and the acquired competences and tools, a case study in the frame of a General Study Programme (GSP) activity derived new aspects related to processes and tools and showed that the CDF shall play a major role in SoS architecting activities. These new types of activities have two main objectives. The first is to derive an evaluated set of architectures based on the customer s preferences and priorities. The second is to identify potential additional services that the designed integrated architecture will be able to fulfil. The role of plenary sessions is to analyse, characterise and adapt the provided assets, interface and integrate them into a consolidated architecture. Gap analyses eventually lead to new assets and systems needed to be integrated to fulfil the requirements and the foreseen services. The general process that ESA CDF has established through which the CDF and Concurrent Engineering (CE) support the design of high-performance SoS is very much user focused. The performance of a system or a SoS can be expressed in terms of number of users or quality of service(s). A given system will always deliver a certain level of performance to a certain user-group. The design of appropriate interfaces between a number of provided or initially considered assets - through the use of the CDF and CE - allows to design a SoS, which increases performance as well as the number of users. Enhanced, new or complementary services can be considered by exploring various architectures, performing design adaptations and/or even adding complementary systems. Like for traditional space mission studies also SoS activities in the CDF are conducted in plenary sessions though due to the higher level of complexity the session frequency was set to one plenary session per week, which has proven to be best combined with several non-plenary splinter meetings of the Architecture Board (AB). During the plenary meetings all team members of the different groups such as customer group, architect group, domain/asset experts, watchkeepers etc are present. Also for SoS architecture activities the five elements of the Concurrent Design approach apply since there is a process in place, there is a multi-disciplinary team, the Integrated Architecture Model (IAM) is applied as well as the facility, software and hardware are used. The general overview on data and information flow as well as the main process building blocks can be synthesised as follows. 1) The data and parameters gathered in the Excel Workbooks are 2) directly imported via the IAM Data Exchange into 3) the architecture tool System Architect (SA). System Architect as well as 4) Focal Point (FP) and Architecture Representation Tool (ART) are described later in this paper. In SA architecture options are modelled while the evaluation of those architectures is done with Focal Point. The results and analyses feed directly back to 5) discussions between the experts. The iterative architecture following the TOGAF-ADM is also described in more detail in the following chapter. Since 2008, studies have been performed such as e.g. Space Situational Awareness, an initial study that provides awareness of what objects are orbiting the Earth / are on an intersecting course with Earth and for as such a threat to people and property on Earth and in space and on their functioning, and a Crisis Response study to provide relative information (maps and imagery) to aid and strategic field agents. Architecture An architecture is the fundamental organisation of a system embodied in its components, their relationships to each other and to the environment and the principles guiding its design and evolution [2]. TOGAF provides the following extension to this definition [1]:

3 A formal description of a system, or a detailed plan of the system at a component level to guide its implementation The structure of components, their inter-relationship and the principles and guidelines governing their design and evolution over time. The different perspectives of an architecture are visualized in, among others, descriptions and architecture views. The rules and guidelines according to which to generate these views are provided by an Architectural Framework. For the CDF SoS studies the NATO Architectural Framework (NAF) is used. This framework adds to the previous definition of architecture: An Architecture can be captured in a formal description of an instance, or configuration of people, processes, systems and organizations, connected by their inter-relationships. An architecture description includes views showing various aspects of the architecture. The views include architectural elements and the relations between elements as governed by a meta-model [3]. Architectural Framework The NATO Architectural Framework is not an architecture itself, but it provides the rules, guidance, and product descriptions for developing, presenting and communicating architectures. The NAF is also the common denominator for understanding, comparing, and integrating architectures. The application of the framework will enable architectures to contribute most effectively to the acquisition and fielding of cost-effective and interoperable (military) capabilities. The framework ensures that the architectures developed can be compared and related across NATO and National boundaries or for ESA applicable architectures covering space and non-space assets. Architectural Views Architectural Frameworks provide a large set of predefined Views with which an architecture can be represented from a variety of viewpoints and in a variety of level of detail. For the CDF SoS activities currently a subset of the available views is being used. This subset can be expanded when required and the scope of the activity extended, possibly assisted as well due to the experience gained during CDF SoS studies by the team members. The subset of the, up till now, standard architectural views is included in the description of the Architecture Development Model below. ARCHITECTURE PROCESS The architecture process involves following the Architecture Development Model s phases, in combination with generating Architectural Views, by application of the chosen Architectural Framework, and corresponding architectural descriptions. This process has been defined in [4]. Architecture Development Model In order to approach the problem of System of Systems design in a structured way a method shall be used that step by step allows the team to address problems one by one, thereby taking all relative aspects into account. Since during a study, progressive insight forces one to return to earlier steps, this method shall have, just like Concurrent Design itself, an iterative nature. The Open Group Architecture Framework (TOGAF) provides the Architecture Development Model (ADM), which has been depicted in Fig. 1 and which fulfils all needs described above. A very good reason for using a structured approach such as the TOGAF-ADM is that it avoids the initial panic when the full scale of the task becomes apparent. [1]. Fig. 1. The TOGAF Architecture Development Model

4 Of the eight TOGAF ADM phases, not all are applied to CDF performed activities. The main reason for this is that the scope of CDF activities is usually limited to (pre-)phase A design and to Phase B reviews of the space project lifecycle. Consequently all TOGAF phases that involve detailed design and practical implementation are therefore out of the scope of the CDF. The activities focus therefore on; TOGAF Phase A, the Architecture Vision, which sets the scope of the CDF SoS activity. Phase B, the Business Architecture, which defines the fundamental organisation of the activity and its business/operations. Phase C, the System Architectures, which defines the fundamental organisation of the system entities involved in the study and Phase D, the Technology Architecture, which documents the fundamental organisation of the systems embodied in hardware, software and communication technology. In addition and in theory, depending on the level of detail of the study and on customer requirements, further phases can be conducted, during which respectively Opportunities and Solutions are defined for moving from the old to the new environment and during which the Migration Planning for moving from baseline to target architecture is being conducted. The ADM revolves and re-iterates around the analysis, adaptation and verification of requirements, which optimises the result and maximises the fulfilment of requirements. In addition it revolves from Phase to Phase, via the requirements or even revolves within a specific phase. The revolving and re-iterating process allows to spiral and converge towards a solution that is optimised, without having to wait with the start of the activity until all initial information is frozen, which is a practical impossibility. The architecture design moves from an as is state to a to be state. In addition to the fulfilment of requirements, the analysis of gaps takes place, which either call for the re-definition of requirements or for a conclusion that earlier defined requirements can be met only to a certain level or not at all. Phase A Phase A sets the scope, constraints and expectations for the study. The following tasks are performed in Phase A: Selection of the study Validation of the business context Create the Statement Of Architecture Work Preparation of tools Definition of requirements / Re-definition of requirements Details are described below. The study defines / describes the business that the enterprise is involved in, which includes the breadth of coverage, the level of detail (e.g. till which ADM Phase the study proceeds and to which level of architecture the study goes), the goals, the drivers, the constraints (e.g. the use or non-use of military assets), the domains to be covered, the time horizons, the stakeholders, the services and the assets that could be considered to provide the services. Tools are being prepared for the conduct of the study, which usually are; Workbooks, System Architect (SA), Coupling of workbooks with System Architect, Focal Point (FP), Architecture Representation Tool (ART), Requirement Check Point (RCP) sheet. Requirements are defined in Phase A or Phase A involves the insertion of earlier defined requirements into the study. Usually these are customer-identified-requirements. These requirements are then complemented by session-identifiedrequirements that come up during sessions due to the iterative nature of the activity and due to progressing insight. Phase B Phase B develops the architecture at business level. The following tasks are performed in Phase B: Develop the baseline ("as is") and Target ("to be") architecture and analyze gaps Identify services that the architecture (SSA) will provide to the end user Identify the organisations that could deliver those services Identify the Operational Nodes hosting these organisations Identify the data that will be exchanged between the nodes Create the "Operational View" (See pictorial example) Set the Requirements Check Point, for review of current architecture against requirements Details are described below. From the in Phase A defined requirements, services are identified that shall be provided to the end user. The breakdown of services occurs till such a level of detail that eventually in Phase C and D the services can be mapped against assets that can provide the required service. For Phase B, the organisations that can provide these services are being identified. Furthermore architecture viewpoints are selected to demonstrate how stakeholder concerns are addressed in the business architecture (use cases). A formal checkpoint review of the architecture model and building blocks is conducted together with stakeholders, in order to validate proper implementation of their needs (service to be provided). If needed the process is repeated till the target architecture has been realised. This is done among others by the analysis of gaps and by the filling of gaps with either existing or new assets, or by accepting the gaps as it is and removing a requirement from the list defined in Phase A, if constraints such as e.g. cost call to do so. The latter described activity of verification

5 of the business level architecture against requirements is done at the Requirement Check Point (RCP). This work shall in theory be performed at every session. The process is documented for future reference and includes the generation of the NAF-defined Operational View Fig. 2. Simplified and de-identified example of a High Level Operational View [N0V-01] for the Deployment of a secure telecommunication link (left) and an Operational View [N0V-02] for the business architecture of an observing architecture (right) Phase C Phase C develops the architecture at systems level. The following tasks are performed in Phase C: Identify which systems could be candidate to provide the identified services System experts provide the parameters and ratings on the candidate systems Develop the System Views e.g. NSV-01 System Interface Description (See pictorial example). This view shows how the systems are connected from a systems perspective, to deliver the services. Normally this is done for each required service. Develop the NSV-12 Service provision diagram, showing the assets that are candidate to provide a required service. Develop the baseline ("as is") and Target ("to be") architecture and analyze gaps Make an evaluation from system perspective only (Focal Point) Set the Requirements Check Point, for review of current architecture against requirements Details are described below. The activity of service breakdown and eventual mapping to assets (systems), starts to take place in Phase C. For the identification of which systems could be candidate to provide the identified services, the NSV-12, Service Provision View, is created (System-Service view Mapping). As a consequence it is this level at which the emergence of a true System of System occurs. In order to validate if the selected assets are capable of providing the required services, the performances of the assets are compared to the earlier defined requirements. In doing so, a qualitative measure is being defined that gives an indication of how well a specific requirement is met (e.g. 100% to 0%). System specific data, required for example for the verification against requirements, but also required for example for cost calculations and risk predictions are provided in this phase by experts on specific assets. Their work is being monitored by independent Watchkeepers that verify if provided values are realistic. Again this phase comprised of iteration from as is to to be architectures, including gap analysis and verification of requirements at the RCP. The output of this phase is in the form of NAF defined system views, the System Interface Description (NSV-01). Different architectural options can, due to the qualitative measures, be compared to each other and the most favourable (from a certain viewpoint e.g. lowest cost, lowest risk, highest governance, level of performance etc.) shall be selected. The latter described activity of verification of the business level architecture against requirements is done at the Requirement Check Point. This work shall in theory be performed at every session. Fig. 3. Simplified and de-identified example of a System View; the (NSV-01), System Interface Description

6 Phase D Phase D develops the architecture at technology level and the following tasks are performed: Develop the baseline ("as is") and Target ("to be") architecture and analyze gaps Develop architecture at technology level Identify the technical standard and forecast, for the candidate systems Details are described below. In this phase the fundamental organisation of systems is documented, embodied in software, hardware and communications technology. The baseline and target technology architecture is developed and the gaps are analyzed The technical standard and forecast of the candidate systems are identified and represented. In addition the service provision view, which has the purpose to illustrate which asset /system contributes to provide a specific service (the Service Provision View (NSV-12) is in that sense a mapping of assets / systems to services) is generated. Additional graphical representation of the SoS architecture in Phase D is achieved by the generation of the Technical Views. TV-1 reflects the current state, TV-2 reflects the future state and TV-3 reflects the technical configuration. Fig. 4. Simplified and de-identified example of a Service Provision View (NSV-12) for the service Detection and Tracking of Man Made Objects Technical domains Short Term Status (+5y) Long Term Status (+15y) Standard Name current TRL Risk reaching TRL9 Standard name current TRL Risk reaching TRL9 Input power low input power 6 RL1 high input power 4 RL0 output rate low output rate 7 RL0 high output rate 3 RL3 Observation request format current format 9 RL0 Format RL1 Orbit description Graves 3-lines 5 RL0 Fig. 5. Simplified example of a Technical View [NTV-2]; Technological standard evolution The remaining phases are out of the scope of CDF activities but are nevertheless mentioned for completeness. Phase E to Phase H Phase E deals with Opportunities and Solutions. In Phase E major implementation projects are identified. The projects that are required in order to fulfil the requirements of the foreseen SoS are listed. Within these (existing) projects phases and parameters of change are identified. Gap analysis is performed between baseline and target architectures in order to determine the areas where additional action is needed. Phase F dealing with Migration Planning analyses cost benefits and risks. An implementation roadmap is developed to achieve the target architecture, starting from the baseline architecture. In order to do this, priorities shall be identified. Phase G deals with Implementation Governance. During this phase the actual foreseen construction of the architecture starts. Contracts are signed and the implementation of the work is monitored. This phase is outside the scope of CDF activities, although governance support can be provided by CDF team members on a need basis. In this phase architecture contracts are prepared and issued by the Implementation Governance Board to ensure that the implementation project conforms to the architecture and experts and the architect follow the project implementation. Phase H deals with Architecture Change Management (outside scope of CDF). During Phase H the implemented architecture is managed and adjusted to changing needs of the enterprise. Iterations occur between phases for minor changes and within new cycles of the ADM for major changes. During this phase it needs to be ensured that the architecture responds to the needs of the enterprise, the architecture is maintained and fine tuned here and there to let it evolve into a well oiled machine. After implementation of the architecture-compliant system, an architecture change management process is put into place to monitor its proper functioning and introduce the possibility to change or enhance the system, corresponding to Phase H. This may be needed due to changing business environment, new technologies arising or existing technologies withdrawing, further cost reductions, etc. The impact of a proposed change is assessed, leading to a change management techniques, partial re-architecture (renewed iteration of certain parts or phases of the TOGAF process) or initiation of a renewed iteration of the whole ADM-cycle.

7 TEAM The CDF SoS study team consists of the customer, a team leader, an architect, a SoS manager, an architect assistant, various experts, and domain experts. Some of the aforementioned team members are also members of the Architectural Board and / or act as Watchkeepers. The customer represents what is reflected as enterprise in the architectural frameworks. The customer can be seen as the one that pays to make nations, organizations, companies, services etc. contribute to the creation of the desired System of Systems. The team leader is responsible for facilitating and chairing all the concurrent sessions and splinter meetings as well as making contractual arrangements for the study. The architect takes care of the architecting work of the business functions, data communication and asset selection according to the rules of the predefined architectural framework. The architect role may be performed by an ESA internal or external expert, depending on specific qualities required. The SoS manager takes care of the overall process and coupling of tools to ensure proper and concurrent functioning of the study. Domain experts represent assets (systems), sometimes on subsystem level for critical issues identified by the architect. An organisation owned asset might want to be represented by an expert of that particular organisation while if an organisation is not present the architect will be acting as asset expert. The full team of domain experts to cover the different views can consist of four communities of stakeholders, the business architecture stakeholder, stakeholders of the system (of systems) architecture including service providers, stakeholders of the subsystem/equipment and the stakeholders of the technical communication & information (including security) architecture. The Architecture Board is comparable to the board of directors of a company and consists of the customer, the architect and representatives of the main stakeholders e.g. customer. The Architecture Board decides between options proposed by the architect and study team during all phases of the study. The Architecture Board s exact composition differs from study to study. The Watchkeepers role is actually performed by domain experts of for example the risk, programmatics, cost and simulation. Since SoS studies often work with existing assets, the Watchkeepers are required to critically assess the inputs provided by the independent asset experts. In this sense, their role differs from traditional concurrent engineering work where none of the technical experts provides, cost, risk, or schedule related information. The Simulation expert verifies the claims made by the asset experts (system/program owners) whenever possible. TOOLS The following software tools are used in the CDF for SoS activities: Excel Workbooks Excel workbooks are provided to asset experts, mainly to be used as data repository. The workbook s output sheet exports sets of mostly static information / parameters, because the systems usually already exist and therefore the information does not change during the sessions. For the above described reasons, the asset expert s workbook input sheets are not used as much as in CDF system studies because for SoS, a change in one system does not per definition influence another system. The Architect s and Watchkeeper s workbooks make more use of the input sheet since for those the change of the information is more significant. According to [4] the workbooks together with the collocated sessions shall be identified as the main added value when comparing CDF s concurrent SoS studies to traditional SoS studies. A positive result of using the Excel workbooks is that the concurrent approach is incorporated, i.e. the very important switches to ensure that all the domain/assets during architecture phases are inline with the current state of the architecture. In addition the use of the workbooks is very flexible and intuitive since it is based on a well known software package. The addition of new parameters, ad-hoc calculations, domain/asset specific business rules, assets, etc. can therefore be implemented swiftly by everybody without additional training. The Architect workbook exports the gathered information in CSV format from the team to the System Architect and Focal point. Integrated Architecture Model (IAM) CDF s Excel based Integrated Design Model (IDM) remains to fulfil a key part of the CDF when SoS studies are being carried out. Adaptations to the models as well as the different way of using, led to the decision to redefine the adapted tool to Integrated Architecture Model (IAM). Usage of the IAM eliminates the need for System Architect software licenses for (almost) all the team members. In addition it creates the convenience for team members to quickly use the familiar Excel based functions of the IAM in order to adapt their models. This would not be possible / straight forward when solely System Architect is used. System Architect software tool System Architect is used to model the architecture according to a predefined set of rules (architectural framework) that are applicable for architectures of this type. The meta-model provides an enormous amount of viewing possibilities and provides underlying information at relevant locations in the architecture that can easily be extracted when needed. Underlying information concerns for example: data communication, protocol format, data ownership and availability, cost, governance and security information, etc., but also concerns the qualitative measure of how well specified requirements are met. The data can be exported easily towards software tools such as Focal Point that is used to evaluate the different architectural options.

8 Focal Point software tool Focal Point is an Evaluation tool. It evaluates the variety of architectures that is being created within System Architect. Focal Point can be used to evaluate the qualitative data of different architectural options to select t the best one from a certain point of view e.g. lowest cost, highest governance, lowest risk, high performance and so on. By sorting the negative aspects from the positive aspects of architectures and by coupling these to weighting factors and business rules, the evaluation is being performed.. Architecture Representation Tool (ART) The Architecture Representation Tool has a dual function of tutoring study participants and presenting results. When used for tutoring it basically reflects the information of this paper in a digital and interactive way with pictorial examples. When used as a presentation tool, it complements the tutoring theory with actual results from the study (e.g. requirements list and architectural views), so a summary of the architectural design is easily accessible to everybody. CDF SOS PERFORMED ACTIVITIES Since end of 2008 the ESA CDF has performed different SoS activities. Besides the first case study two additional activities on a Crisis Response initiative were conducted in eight respectively six plenary and several non-plenary sessions and meetings. More than 30 people in roles of customer, experts, consultant and support were involved representing the four largest ESA establishments, ESA-HQ, ESOC, ESRIN and ESTEC, and eight ESA directorates. Currently an activity on System Requirements identification is performed in a in the form of an incremental, collaborative review to allow ESA to closely follow the progress of the work performed in industry; to perform technical monitoring of the industrial activities through coordination, consolidation, analysis and discussion with industry, during CDF led so called Industry Sessions (IS), as well as within the CDF study team and during Architecture Board Sessions (ABS); and to provide industry with guidance on a regular basis (IS) and feedback, based on internal architecture activities (ABS). During iterating sessions asset and domain information as well as architectures provided by industry is assessed, if needed appropriately adapted and feedback provided according to the CDF-SoS methodology. This approach will contribute to a common understanding, strategy and overall planning on both sides (ESA and industry) from the very beginning and finally prepare the parties to an effective and stream-lined System Requirement Review. REFERENCES [1] TOGAF version Enterprise edition A pocket guide, The Open Group, Van Haren publishing, Zaltbommel, ISBN , 2007 [2] [3] NATO ARCHITECTURE FRAMEWORK Version 3, NAT v.3. Enabling NNEC for NATO, Annex 1 to AC/322-D(2007)0048 [4] System of Systems Reference Models Final Report, TAS Ref: ; ESA Contract No /07/NL/HE dated 06/05/2009. ACKNOWLEDGEMENTS The CDF SoS study team would like to thank: The General Study Programme (GSP) for funding the initial System of Systems activities The customers and team members of the up till now conducted studies Massimo Bandecchi for bringing System of Systems activities to the Concurrent Design Facility