Engineering large systems of systems using an Architecture framework

Transcription

1 Engineering large systems of systems using an Architecture framework 1

2 Authors Edvin Hadziefendic, Syntell (presenter) Lars-Olof Kihlström, Syntell 2

3 Syntell is an independent consulting and training partner with proven methods for the development and streamlining of operations, organizations, processes and governance, was started in 1994 and has specialized in products and services that optimize the systems of the customers from a market and life cycle perspective, has a very long experience as regards system engineering including model based system engineering, is an active member of INCOSE (International Council On System Engineering), is an active member of OMG (Object Management Group). 3

4 Architecture frameworks? Drawing from experience gained by working on the development of, and dealing with, NAF 3.0 and 3.1 (NATO architecture framework), MODAF (Ministry of Defence architecture framework), DoDAF (Department of Defense Architecture Framework) and finally as part of the core team developing UPDM (Unified Profile for DoDAF and MODAF (in its latest version renamed to UAF (Unified Architecture Profile) an approach to system engineering that makes use of UAF has been made possible. UAF is based totally on SysML (System modelling language) and exists both as a conceptual meta model (in order to allow non-uml tools to implement UAF) and as a UML based profile that extends SysML. 4

5 Systems of systems engineering? As part of actual projects that made use of SysML as well as UAF it has been shown that UAF, used properly, can be used as a means to make development of actual systems more effective as well as more accurate. The approach emphasizes the logical requirements of the systems of systems as part of a non-implementational specific description of how the system of system is to work. This description can then be reused to a large extent as part of the real development of the systems needed within the systems of systems context under consideration. 5

6 Enterprise goal Maps to Maps to Consumes Operational activity Is a goal of Contains Performs Has Enterprise vision Actual enterprise phase Operational port Is a vision for Defines Exhibits Operational agent Operational performer Known resource Operational exchanges Operational architecture Capability Operational interface Exhibits Implements Depends on/ specializes/ contains Owned by Security control Provides status for Data element Resource port Has Mitigates Data model Contains Defines Resource exchanges Is part of Information element Contains Risk Project actual Actual Project milestone Owned by Resource interface Contains Affects resource and operational elements Requirement Links to all elements Standard Links to all elements Measurement Links to all elements Service specification Has Service port Implements Defines Function Specializes / contains Performs Resource performer Resource architecture Known resource System Capability configuration Physical resource Resource Software artefact Security enclave Natural resource Organisational resource Responsibility Person Organization Post Classified by Specializes/ contains Actual resource Fielded capability Actual organisational resource Actual Actual Actual post person otganisation implements Service interface 6

7 The example used to demonstrate the approach NATO has approved NAF version 4 as its architecture framework and stated that they accept architectures making use of two different meta-models as applicable for NAF version 4 architectures, namely UAF from OMG and Archimate from Open Group. NATO also described an example that they would like to see defined using UAF and Archimate. The example is based on Search and Rescue and has been around for some time as part of different example architectures. The example described by NATO contains a couple of additional twists and lends itself readily to system of systems considerations and in the approach described here has been expanded quite a lot. 7

8 The SAR example Key concepts in the NATO example and system of system extensions: Three countries (Blue, Green and Yellow) each have search and rescue organizations. Via a collaboration organization called Rainbow they are going to work together concerning SAR, across a common sea area containing both national sea areas as well as international sea areas. By extending the example in various areas it becomes possible to explore system of system issues and also define developments that can take place and then define that different systems that needs to be developed over time to increase collaboration. 8

9 Extensions to the example made in this model Fuor time periods (called phases) have been defined in order to describe how an organization can increase its operational abilities. The first phase (named 0) is simply preparation. The key change on the first phase is that basic resource collaboration among the participating nations will become possible. It also introduces the use of a few external services dealing with localization and weather and sea information. The key change is the second phase is increased resource collaboration as well as the use of an external service that ensures that all participating resources in a given mission have a common operational picture. The third phase extends collaboration even further and introduces an approach to mission auditing abilities as well as automated resource decision making. 9

10 How should the SAR capabilities develop? The capabilities for phase 1, 2 and 3 are shown and as can be seen they are extended as the phases change. Maritime SAR phase x acts as the cotainer for all the capabilities needed for a given phase. Some capabilities are common to all and therefore some are coleected in a generic Maritime SAR capability and then inherited by all the other phases.. 10

11 How should the SAR capabilities develop? The capabilities for phase 1, 2 and 3 are shown and as can be seen they are extended as the phases change. Maritime SAR phase x acts as the cotainer for all the capabilities needed for a given phase. Some capabilities are common to all and therefore some are coleected in a generic Maritime SAR capability and then inherited by all the other phases.. 11

12 The capabilities for phase 1, 2 and 3 are shown and as can be seen they are extended as the phases change. Maritime SAR phase x acts as the cotainer for all the capabilities needed for a given phase. Some capabilities are common to all and therefore some are coleected in a generic Maritime SAR capability and then inherited by all the other phases.. 12

13 The capabilities for phase 1, 2 and 3 are shown and as can be seen they are extended as the phases change. Maritime SAR phase x acts as the cotainer for all the capabilities needed for a given phase. Some capabilities are common to all and therefore some are coleected in a generic Maritime SAR capability and then inherited by all the other phases.. 13

14 What can we say about the time periods? For each of the time periods that the model considers, dates, goals and visions can be defined. 14

15 What can we say about the time periods? For each of the time periods that the model considers, dates, goals and visions can be defined. 15

16 For each of the time periods that the model considers, dates, goals and visions can be defined. 16

17 For each of the time periods that the model considers, dates, goals and visions can be defined. 17

18 For each of the time periods that the model considers, dates, goals and visions can be defined. 18

19 Requirements and tool environment integration In order for the example to be useful requirements for the complete system of systems are needed as well. Requirements are usually managed in a separate tool but has to be brought into the overall model. For the example, stakeholder as well as system requirements have been put together from the point of view of the organization managing the collaboration in between the countries. The tool as well as requirements handling made use of for the example: Om the right hand side, the connections towards the external requirements is shown where use of the datahub has been made. On the left hand side, the requirements have been imported as SysML requirements. A synchronization scheme has been defined whereby synchronization is made from the external tool tol the model, i.e. if there are changes in the external requirements the local requirements in the model can be synchronized to these changes. How synchronization as well as management of the impact of changes can be set up as desirec within the project. 19

20 The complete context for system of system is shown here for all of the phases one after the other. At first there does not seem to be much difference between phase 1 and phase 2. But the upper right corner shows a difference. This is where access to external services are being shown and the service access is not the same between phase 1 and phase 2. In the second phase a collaboration service is in place which is not present in phase 1. In the last phase there are differences however, a completely new element has appeared in the form of a distributed ledger. The is logically intended to meet the stakeholder requirement attached to it. The reason for this should be fairly clear. Any large maritime disaster with an ensuing rescue operation will start a major scrutiny effort and the ledger should be capable of providing a clear and unalterable log of exactly what decisions were taken. 20

21 The complete context for system of system is shown here for all of the phases one after the other. At first there does not seem to be much difference between phase 1 and phase 2. But the upper right corner shows a difference. This is where access to external services are being shown and the service access is not the same between phase 1 and phase 2. In the second phase a collaboration service is in place which is not present in phase 1. In the last phase there are differences however, a completely new element has appeared in the form of a distributed ledger. The is logically intended to meet the stakeholder requirement attached to it. The reason for this should be fairly clear. Any large maritime disaster with an ensuing rescue operation will start a major scrutiny effort and the ledger should be capable of providing a clear and unalterable log of exactly what decisions were taken. 21

22 The complete context for system of system is shown here for all of the phases one after the other. At first there does not seem to be much difference between phase 1 and phase 2. But the upper right corner shows a difference. This is where access to external services are being shown and the service access is not the same between phase 1 and phase 2. In the second phase a collaboration service is in place which is not present in phase 1. In the last phase there are differences however, a completely new element has appeared in the form of a distributed ledger. The is logically intended to meet the stakeholder requirement attached to it. The reason for this should be fairly clear. Any large maritime disaster with an ensuing rescue operation will start a major scrutiny effort and the ledger should be capable of providing a clear and unalterable log of exactly what decisions were taken. 22

23 All of these elements provide context for the SAR system of systems. The countries contain the elements that are of importance government, health service (where injured persons from a maritime disaster will finally end up), an oversight organisation (most governments have these) and finally the press which obviously will demand information concerning any significant maritame disaster and rescue operation. The rainbow organisation contains entities that deal with acquisition of joint resources. Assessment of past operations. Coordination efforts between the countries involved as well as planning for the future. The difference between phase 1 and 2 (common) and phase 3 is simply that additional access to the distributed ledger as well as the operations themselves has been added in order to manage detailed monitoring of the efforts. 23

24 All of these elements provide context for the SAR system of systems. The countries contain the elements that are of importance government, health service (where injured persons from a maritime disaster will finally end up), an oversight organisation (most governments have these) and finally the press which obviously will demand information concerning any significant maritame disaster and rescue operation. The rainbow organisation contains entities that deal with acquisition of joint resources. Assessment of past operations. Coordination efforts between the countries involved as well as planning for the future. The difference between phase 1 and 2 (common) and phase 3 is simply that additional access to the distributed ledger as well as the operations themselves has been added in order to manage detailed monitoring of the efforts. 24

25 This completes the context for the three SAR organizations and indicates the elements that they need to interact with: The vessels in distress Weather and sea The rafts that may or may not exist, either alone or associated with a larger vessel. Vessels that are not part of the SAR respurces but may be close and have an ability to offer aid. The radio communications environment that logically influences the information flow in between the elements. The three SAR organizations and their resources. A key logical issue is to describe the criteria under which a given mission is dealt with by which sar organisation 25

26 The SAR assets are in the example essentially the same from the start for countries Blue, Green and Yellow. However, in a real situation, there would presumably be differences in between the countries and the division into distinct elements would then make it possible to let the model easily show these differences. It should also be noted that when the model is instantiated, theer may well be large differences in between the paraneters that characterize each kind of asset as well as in between assets of the same type. The differences in between phase 1, 2 and 3 also appear in the informatio flows that are depicted in each phase representation. There may not seem to be all that many differences in between pase 1 and phase 3 but the ones that exist are significant. Looking at each of the elements a number of considerations that need to be dealt with appears: Safe place: As SAR missions are started, one or more safe places will be needed for the mission. The intent of these is to provide medical treatment and then, if needed, ship patients to hospitals. The locations will need to be established based on the assets made us of for the mission. In case there are more than one mission ongoing the safe place may be co-used between missions. Asset control: It is assumed that the assets themselves are under the command of a special asset control element, i.e. the SAR tactical C2 wiill request resources from 26

27 the asset control and return them once the nmission is completed. In phase 1 and 2 requests are performed by the tactical C2 assigned for a given mission. In phase 3 this is done by the external service. Seabrn asset and airbrn asset: Rather than determining whether assets are search or rescue assets, the logically dividing charateristic is whether they are airborne or seaborne. The asset itself can be either search, rescue or search and rescue. The kind of equipent and crew as well as the number of positions available for distressed persons are also important. The logic of the operational handling will depend a lot on the kind of asset being considered and the characteristics of the asset. Distress monitoring: It is assumed that there will be more than one distress monitoring station. This means that there is a needs to determine whether different distress signals coming from different stations concern the same distress situation or different ones. This is determined in phase 1 and 2 by tactical C2. In Phase 3 this determination is made by an external service which also allocates tactical command responsibility. Tactical C2: Since there may be more than one SAR mission in progress at a given point the tactical C2 needs to be abe to establish different tactical mission teams. In phase 1 and 2 the tactical C2 of the different countries have to determine who is going to be in charge of a given mission. The C2 also has to request assets from the asset control that seem appropriate for the mission once given command of a mission. In phase 3 this determination is made by an external service. 26

28 SAR Blue (same as yellow and green) The SAR assets are in the example essentially the same from the start for countries Blue, Green and Yellow. However, in a real situation, there would presumably be differences in between the countries and the division into distinct elements would then make it possible to let the model easily show these differences. It should also be noted that when the model is instantiated, theer may well be large differences in between the paraneters that characterize each kind of asset as well as in between assets of the same type. The differences in between phase 1, 2 and 3 also appear in the informatio flows that are depicted in each phase representation. There may not seem to be all that many differences in between pase 1 and phase 3 but the ones that exist are significant. Looking at each of the elements a number of considerations that need to be dealt with appears: Safe place: As SAR missions are started, one or more safe places will be needed for the mission. The intent of these is to provide medical treatment and then, if needed, ship patients to hospitals. The locations will need to be established based on the assets made us of for the mission. In case there are more than one mission ongoing the safe place may be co-used between missions. Asset control: It is assumed that the assets themselves are under the command of a special asset control element, i.e. the SAR tactical C2 wiill request resources from 27

29 the asset control and return them once the nmission is completed. In phase 1 and 2 requests are performed by the tactical C2 assigned for a given mission. In phase 3 this is done by the external service. Seabrn asset and airbrn asset: Rather than determining whether assets are search or rescue assets, the logically dividing charateristic is whether they are airborne or seaborne. The asset itself can be either search, rescue or search and rescue. The kind of equipent and crew as well as the number of positions available for distressed persons are also important. The logic of the operational handling will depend a lot on the kind of asset being considered and the characteristics of the asset. Distress monitoring: It is assumed that there will be more than one distress monitoring station. This means that there is a needs to determine whether different distress signals coming from different stations concern the same distress situation or different ones. This is determined in phase 1 and 2 by tactical C2. In Phase 3 this determination is made by an external service which also allocates tactical command responsibility. Tactical C2: Since there may be more than one SAR mission in progress at a given point the tactical C2 needs to be abe to establish different tactical mission teams. In phase 1 and 2 the tactical C2 of the different countries have to determine who is going to be in charge of a given mission. The C2 also has to request assets from the asset control that seem appropriate for the mission once given command of a mission. In phase 3 this determination is made by an external service. 27

30 Detailed logical information handling Here the complete logical interfaces that the monitor needs to deal with is displayed. The upper 5 are common to all phases wheras the last interface only exists in phase 3. OpCntxtMntrBlueIF contains configuration data for the monitor, things like location and a few other static values or start values for elements that may be changed. OpCommMntrBlueIF contains the two signals that the monitor can receive from vessels or rafts in distress. It is assumed that larger vessels will be capable of supplying quite detailed nformation whereas rafts have a basic simple distress signal that does not provide any great amount of information other than a basic SOS. OpMntrMsarBlueIF contains the signals that are exchanged between the Blue tactical centre and the monitoring station. It is assumed that the monitor can distinguish between distress signals that have different vessel or raft origins and that an identity can be managed that is retained for all signals that have the same origin. OpMntrCoordGreenIF and OpMntrCoordYellowIF show signals that are sent to other countries if these countries have been given tactical command of a given mission. 28

31 OpBlueMntrDistledgIF show the signals that are exchanged between the monitoring station and the distributed ledger in phase 3. The above also gives some feeling for the amount of logical information that has to be maintained irrespective of implementation. 28

32 The logic of each of the elements are defined by a state machine (a simple one exemplified) This is a simpe state machine example showing the logic for the distress monitoring station. The state machines for the others are more complex. There does not seem to be a difference between phas 1,2 and phase 3. The key difference is from where the signal OpDistressSignalTactiocalCommandAssigned originates from. In phase 3 this signal is the result of a smart contract in the distributed ledger invoking a service, getting a response back and sending the signal back to the monitor in question. It should be noted that a new distress signal for one monitor may already have had assignments made. 29

33 The Distributed ledger has been divided into three miners, one ach for the different countries, a control element and a ledger node. The miners as well as the ledger node store the block chanin containing all of the transactions in the form of linked blocks. In order to facilitate the handling of the blocks for each mission each mission is assumed to act as a sub channel within the total blockchain, thus ensuring tht transactions associated with a given mission are easy to find (i.e. each mission acts as a subchannel root). The miners are the ones that perform the defined hash calculations required and the one completing a correct calculation first is the one that gets to add a block to the blockchain. The sub channel approach implies that there will be several calculations ongoing in parallell if there are more than one SAR mission in progress at the same time. The calculation effort is initiated by the controller that also ensures that all miners operate on the same set of transactions. The logic required here is defined with the logical state machine that exists for each of the elements. This representation should make it possible for different prioviders of the actual block chain to have a very accurate set of requirements as to what they need to do. It has been assumed that each country will supply its own miner and some of the ledger nodes. The controller will need to be procured and managed by the rainbow organisation. A defined API towards the 30

34 blockchain will ensure that accurate reports and audits of the different SAR missions can be handled. 30

35 How does this aid the system engineering task? In order to determine this, the different elements that will need to be procured/developed to support the enterprise need to be considered. These are: Weather and location services: By defining the relevant parameters as well as the expected logical API, these can be procured. The team handling systems in the tactical centre will need to be dealt with, i.e. they need to be able to access the services. The phase 2 collaboration service will require a core system as well as a client system that needs to be installed at each team handling a SAR mission within the tactical centre, the asset control centre, the airborne assets and the seaborne assets. A distributed ledger will have to be procured/ developed that contains smart contract handling to access an external oracle that can decide which tactical centre is to assume control of a mission and which assets should be used and from whom they should be obtained. In phase 3, the collaboration service needs to be upgraded to take the distributed ledger into account. 31

36 The service specifications As part of the system engineering effort, parameters that can be used to evaluate the service provisions proposed by different suppliers need to be considered. It also needs to be made clear to potential supplier that it is assumed that the localisation and weather functionality provided by the previosuly defined services are assumed to be handled by the collaboration services as well. As services are specified in a loosely coupled manner, the weather and localisation services are shown as parts within the collaboration service. This allows the provider to reuse the specifications for these services without having the model define them once again (i.e. specification reuse). The provider may however elect any means the is felt appropriate to achieve this. A set of measurement attributes have also been defined for the services that the provider should be prepared to respond to based on the service levels required by the Rainbow organisation. A possible set of service level values can be seen here. The elements made use of are typed by value types in SysML (some of the types are enumeration) and these are associated with both quatity kinds as well as units making it possible to determine exactly what the values mean. 32

37 As part of the system engineering effort, parameters that can be used to evaluate the service provisions proposed by different suppliers need to be considered. It also needs to be made clear to potential supplier that it is assumed that the localisation and weather functionality provided by the previosuly defined services are assumed to be handled by the collaboration services as well. As services are specified in a loosely coupled manner, the weather and localisation services are shown as parts within the collaboration service. This allows the provider to reuse the specifications for these services without having the model define them once again (i.e. specification reuse). The provider may however elect any means the is felt appropriate to achieve this. A set of measurement attributes have also been defined for the services that the provider should be prepared to respond to based on the service levels required by the Rainbow organisation. A possible set of service level values can be seen here. The elements made use of are typed by value types in SysML (some of the types are enumeration) and these are associated with both quatity kinds as well as units making it possible to determine exactly what the values mean. 33

38 The service interfaces The interfaces of the different services are defined based on the way it is intended to support the operational logic as defined by the elements described within the operational model. As can be seen the amount of information required logically quickly expands. 34

39 The interfaces of the different services are defined based on the way it is intended to support the operational logic as defined by the elements described within the operational model. As can be seen the amount of information required logically quickly expands. 35

40 The interfaces of the different services are defined based on the way it is intended to support the operational logic as defined by the elements described within the operational model. As can be seen the amount of information required logically quickly expands. 36

41 The service interfaces The interfaces of the different services are defined based on the way it is intended to support the operational logic as defined by the elements described within the operational model. As can be seen the amount of information required logically quickly expands. 37

42 Resources that have to be developed These different elements are a set of physical resources that contain realised functionality required by the Rainbow organisation. The following different pieces of machinery can be said to fall under the purview of the rainbow oganisation, i.e. they need to procure and equip the different SAR organisations with thi hardware. CollaborationServiceHwPhase2: The external service that keeps track of and ensures that all elements participating in a SAR Mission has a common operational picture of the mission. CollaborationServiceHwPhase3: The same as above but with addition of the transmission of all transactions towards the distributed ledger. TacticalC2AndResourcesDeterminationServiceHw: The external service that makes a decision on what resources are required for a given mission, requests them from one or more SAR organizations and decides which tactical C2 is to assume total command. It should be noted that once this has been done the service resets itself as far as its decisions are concerned. AssetCommandCollaborationHwPhase2: The client within the asset control element that handles received information from the Collaboration service and is responsible 38

43 for status updates back to the collaboration service concerning itself. AssetCommandCollaborationHwPhase3: The same as above with the addition of transaction logging in the distributed ledger. MissionCollaborationAirborneHwPhase2: The client within the airborne element that handles received information from the Collaboration service and is responsible for status updates back to the collaboration service concerning itself. It should be noted that if this element is autonomous it is only possible to handle searches and may not need an HMI since there is noonwe onboard. MissionCollaborationAirborneHwPhase2: The same as above with the addition of transaction logging in the distributed ledger. MissionCollaborationSeaborneHwPhase2: The client within the seaborne element that handles received information from the Collaboration service and is responsible for status updates back to the collaboration service concerning itself. It should be noted that if this element is autonomous it is only possible to handle searches and may not need an HMI since there is noonwe onboard MissionCollaborationSeaborneHwPhase3: The same as above with the addition of transaction logging in the distributed ledger. 38

44 The collaboration service The Collaboration swervice is an external piece of hardware (containing software) that needs to interface both with terrestrial communications (weather and sea service, localisation service as well as asset control and tactical C2) well as Radio (Airborne and Seaborne). In order to deal with this adaptors in between the hardware abd the collaboration software application has been used. Since the service needs to be able to deal with different missions in parallell more than one individual collaboration may be required. When looking at the software architecture for an individual collaboration as part of the service, it becomes apparent that many of the same element kinds as was available in the logical model reappears. This reuse goes a lot further than simple element naming most of the information elements defined in the logical model reappears as does much of the detailed logic contained within the state machines of the logical model. The reuse is not 100 %, there are parts that need to be handled somewhat differently. The reuse estimates vary from model to model where an object oriented approach is applied from the start as part of the logical model (as opposed to a functionality based approach), but will be quite high. 39

45 The collaboration service The Collaboration swervice is an external piece of hardware (containing software) that needs to interface both with terrestrial communications (weather and sea service, localisation service as well as asset control and tactical C2) well as Radio (Airborne and Seaborne). In order to deal with this adaptors in between the hardware abd the collaboration software application has been used. Since the service needs to be able to deal with different missions in parallell more than one individual collaboration may be required. When looking at the software architecture for an individual collaboration as part of the service, it becomes apparent that many of the same element kinds as was available in the logical model reappears. This reuse goes a lot further than simple element naming most of the information elements defined in the logical model reappears as does much of the detailed logic contained within the state machines of the logical model. The reuse is not 100 %, there are parts that need to be handled somewhat differently. The reuse estimates vary from model to model where an object oriented approach is applied from the start as part of the logical model (as opposed to a functionality based approach), but will be quite high. 40

46 The collaboration service The Collaboration swervice is an external piece of hardware (containing software) that needs to interface both with terrestrial communications (weather and sea service, localisation service as well as asset control and tactical C2) well as Radio (Airborne and Seaborne). In order to deal with this adaptors in between the hardware abd the collaboration software application has been used. Since the service needs to be able to deal with different missions in parallell more than one individual collaboration may be required. When looking at the software architecture for an individual collaboration as part of the service, it becomes apparent that many of the same element kinds as was available in the logical model reappears. This reuse goes a lot further than simple element naming most of the information elements defined in the logical model reappears as does much of the detailed logic contained within the state machines of the logical model. The reuse is not 100 %, there are parts that need to be handled somewhat differently. The reuse estimates vary from model to model where an object oriented approach is applied from the start as part of the logical model (as opposed to a functionality based approach), but will be quite high. 41

47 A mission collaboration hardware needs to be inserted into the seaborne vessel. Since the only way of communicating is through Radio a Radio adaptor is needed as well. There may or may not be a HMI for this collaboration (if the airborne vessel is autonomous, an HMI may not be required). If an HMI is present, an adaptor for it will be required as well. There will also be a need for connection to general data from the airborne vessel and therefore, an adaptor for this is required as well. When the software application is broken up into smaller pieces, the elements from the logical model start to make an appearance again. Also here the reuse goes further than naming and resuses information as well as logic defined in the logical model. The above represents the picture of the mission as seen from a single airborne asset, It should be noted that there is a distinction between this airborn asset and possible other airborne assets that are part of the mission. 42

48 A mission collaboration hardware needs to be inserted into the seaborne vessel. Since the only way of communicating is through Radio a Radio adaptor is needed as well. There may or may not be a HMI for this collaboration (if the airborne vessel is autonomous, an HMI may not be required). If an HMI is present, an adaptor for it will be required as well. There will also be a need for connection to general data from the airborne vessel and therefore, an adaptor for this is required as well. When the software application is broken up into smaller pieces, the elements from the logical model start to make an appearance again. Also here the reuse goes further than naming and resuses information as well as logic defined in the logical model. The above represents the picture of the mission as seen from a single airborne asset, It should be noted that there is a distinction between this airborn asset and possible other airborne assets that are part of the mission. 43

49 Hardware for this service will also be required and as this service only accesses elements that are connected terrestrially only one kind of adaptor is required. As the software required for this service is detailed further, the same kind of elements as in the logical model appears once again and once again resuse is possible to a great extent. The logic of this service can be described as follows: Once activated the service will retrieve possible assets from each of the yellow, blue and green countries (these elements are hidden beneath the Xassets elements that have internal parts). Once the smart contract of the distributed ledger invokes this service information as to the vessel in distress possible rafts as well as a possible tactical C2 is established. Based on the information a determination is made concerfning the number of possible resources needed are calculated. Requests from the required reqources are sent to the asset holders (somettimes one specific and sometimes all depending on the kind of emwergency and the location of the action). Once a set of resources has been assembled and a tactical C2 has been determined, the service issues its mission result and awaits another invocation. 44

50 Hardware for this service will also be required and as this service only accesses elements that are connected terrestrially only one kind of adaptor is required. As the software required for this service is detailed further, the same kind of elements as in the logical model appears once again and once again resuse is possible to a great extent. The logic of this service can be described as follows: Once activated the service will retrieve possible assets from each of the yellow, blue and green countries (these elements are hidden beneath the Xassets elements that have internal parts). Once the smart contract of the distributed ledger invokes this service information as to the vessel in distress possible rafts as well as a possible tactical C2 is established. Based on the information a determination is made concerfning the number of possible resources needed are calculated. Requests from the required reqources are sent to the asset holders (somettimes one specific and sometimes all depending on the kind of emwergency and the location of the action). Once a set of resources has been assembled and a tactical C2 has been determined, the service issues its mission result and awaits another invocation. 45

51 Conclusion and questions The intent of this presentation was to show that an architecture framework has a definite place as part of a system engineering effort associated with a system of systems definition (in this case an enterprise undergoing development). It could be argued that the resource detailing as regards architecture goes to far. However there is an added advantage that the end customer can benefit from if an approach of this nature is adopted. This benefit has to do with change and change management. Given the closeness of the resource models to elements in the actual operational model, any change to the way the enterprise is handled can be dealt with by simply doing the same thing in the resources themselves (if there is a decision to combine the asset control and the tactical centre into a single entity, exactly the same thing should be done in the models and the software). This make maintenance easy and has a direct impact on life cycle costs. 46