Military Communications and Information Technology: A Trusted ...

Military Communications and Information Technology: A Trusted ... Military Communications and Information Technology: A Trusted ...

22.01.2015 Views

204 Military Communications and Information Technology... • The pragmatic layer recognizes the patterns in which data are organized for the information exchange, which are in particular the inputs and outputs of procedures and methods to be called. This is the context in which data are exchanged as applicable information. These groups are often referred to as (business) objects. This is the highest level still supporting the realm interoperability; the relations between functions and there input and output parameters are captured. • The dynamic layer recognizes various system states, including the possibility for agile and adaptive systems. The same business object exchanged with different systems can trigger very different reactions. It is also possible that the same information sent to the same system at different times can trigger different responses. This level is the first level in the realm of composability, as it requires the alignment of assumptions and constraints. • Finally, general assumptions, constraints, and simplifications need to be captured. This happens in the conceptual layer. Here, we capture the abstractions and simplifications of the perception of reality that constraint the model. The following figure shows the levels and their relation to the governing interoperation concepts. Figure 1. Levels of Conceptual Interoperability Model This model already implies that more than data mediation is needed to support composability. The context needed to support meaningful use of information to be exchanged must address the higher levels of interoperation as well. Interoperability design The main idea behind most interoperability engineering approaches was the requirement that the original systems that shall contribute to a distributed application

Chapter 3: Information Technology for Interoperability and Decision... 205 shall not be modified. This also explains the focus on data mediation and providing middleware solutions to integrate such systems in support of a common operation. However, the LCIM shows that this cannot be sufficient. The context of the information exchange setting the intended use is as important as the information itself. While the LCIM already shows the need for better aligned of the systems holistically, model theory can be used to proof the necessity. Model theory is a branch of mathematics that deals with the interpretation of formal languages using set-theoretic structures. The topic of research is the equivalency of interpretations in different formal languages. In other words, model theory is the study of the interpretation of languages and how truth is interpreted within the language. The underlying questions are: How can we ensure that truth is consistently represented, and what does this mean for the formal languages It seems to be logical to think about formal languages when talking about implementations, as programs are written in computer languages, and computer languages are formal languages. However, we use artifacts such as the Unified Modeling Language (UML) or the System Modeling Language (SysML) for the modeling phase, and they can be interpreted as formal languages as well. Collections like the NATO Architecture Framework that are based on a common repository storing all artifacts and diagrams are formal languages as well. In order for requirements to make sense, they need to be verifiable, which normally happens in form of measuring something. SysML defines the requirement diagram and the parametrics diagram to deal with these tasks systematically; architecture framework tools support the annotation of functions with acceptance test metrics as well. However, if we can measure it, we can express it in a formal language. Finally, validation and verification ensure the equivalency of transformations between different views of the model, which can be expressed formally. If we therefore can show the applicability of model theory to the tasks of semantic interoperability, we can hope for a new unifying approach that embraces requirements, modeling, implementation, and validation and verification. Therefore, model theory becomes the unifying theory that brings systems engineering, modeling and simulation, and validation and verification together and builds a formal basis to meaningfully and unambiguously discuss interoperability. In order to understand the applicability of model theory as the foundation for a common interoperability theory, several definitions are necessary. We start with definitions for a language, universe and interpretation building the structure of the language, and finally sentences built and understood in this language. • Definition 1: A language L is a set consisting of logical symbols including constant symbols, function symbols, and relational symbols. • Definition 2: A structure for a language L is an ordered pair . A is a set of symbols. Rn is a relation defined over A such that (a 1 , …, a n )Rn if and only if a function f exists that fulfills f(a 1 , …, a n-1 ) = a n . The set part A is called the universe of a language, as they describe everything that can be

204 <strong>Military</strong> <strong>Communications</strong> <strong>and</strong> <strong>Information</strong> <strong>Technology</strong>...<br />

• The pragmatic layer recognizes the patterns in which data are organized for<br />

the information exchange, which are in particular the inputs <strong>and</strong> outputs<br />

of procedures <strong>and</strong> methods to be called. This is the context in which data<br />

are exchanged as applicable information. These groups are often referred<br />

to as (business) objects. This is the highest level still supporting the realm<br />

interoperability; the relations between functions <strong>and</strong> there input <strong>and</strong> output<br />

parameters are captured.<br />

• The dynamic layer recognizes various system states, including the possibility<br />

for agile <strong>and</strong> adaptive systems. The same business object exchanged with<br />

different systems can trigger very different reactions. It is also possible that<br />

the same information sent to the same system at different times can trigger<br />

different responses. This level is the first level in the realm of composability,<br />

as it requires the alignment of assumptions <strong>and</strong> constraints.<br />

• Finally, general assumptions, constraints, <strong>and</strong> simplifications need to be captured.<br />

This happens in the conceptual layer. Here, we capture the abstractions<br />

<strong>and</strong> simplifications of the perception of reality that constraint the model.<br />

The following figure shows the levels <strong>and</strong> their relation to the governing<br />

interoperation concepts.<br />

Figure 1. Levels of Conceptual Interoperability Model<br />

This model already implies that more than data mediation is needed to support<br />

composability. The context needed to support meaningful use of information to be<br />

exchanged must address the higher levels of interoperation as well.<br />

Interoperability design<br />

The main idea behind most interoperability engineering approaches was the requirement<br />

that the original systems that shall contribute to a distributed application

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!