Military Communications and Information Technology: A Trusted ...
Military Communications and Information Technology: A Trusted ... Military Communications and Information Technology: A Trusted ...
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
- Page 153 and 154: Chapter 2: Communications and Infor
- Page 155 and 156: Chapter 2: Communications and Infor
- Page 157 and 158: Chapter 2: Communications and Infor
- Page 159: Chapter 2: Communications and Infor
- Page 162 and 163: 162 Military Communications and Inf
- Page 164 and 165: 164 Military Communications and Inf
- Page 166 and 167: 166 Military Communications and Inf
- Page 168 and 169: 168 Military Communications and Inf
- Page 170 and 171: 170 Military Communications and Inf
- Page 172 and 173: 172 Military Communications and Inf
- Page 174 and 175: 174 Military Communications and Inf
- Page 176 and 177: 176 Military Communications and Inf
- Page 178 and 179: 178 Military Communications and Inf
- Page 180 and 181: 180 Military Communications and Inf
- Page 182 and 183: 182 Military Communications and Inf
- Page 184 and 185: 184 Military Communications and Inf
- Page 186 and 187: 186 Military Communications and Inf
- Page 188 and 189: 188 Military Communications and Inf
- Page 190 and 191: 190 Military Communications and Inf
- Page 192 and 193: 192 Military Communications and Inf
- Page 194 and 195: 194 Military Communications and Inf
- Page 196 and 197: 196 Military Communications and Inf
- Page 199: Chapter 3 Information Technology fo
- Page 202 and 203: 202 Military Communications and Inf
- Page 206 and 207: 206 Military Communications and Inf
- Page 208 and 209: 208 Military Communications and Inf
- Page 210 and 211: 210 Military Communications and Inf
- Page 212 and 213: 212 Military Communications and Inf
- Page 214 and 215: 214 Military Communications and Inf
- Page 216 and 217: 216 Military Communications and Inf
- Page 218 and 219: 218 Military Communications and Inf
- Page 220 and 221: 220 Military Communications and Inf
- Page 222 and 223: 222 Military Communications and Inf
- Page 224 and 225: 224 Military Communications and Inf
- Page 226 and 227: 226 Military Communications and Inf
- Page 228 and 229: 228 Military Communications and Inf
- Page 230 and 231: 230 Military Communications and Inf
- Page 232 and 233: 232 Military Communications and Inf
- Page 234 and 235: 234 Military Communications and Inf
- Page 236 and 237: 236 Military Communications and Inf
- Page 239 and 240: Run-Time Ontology on the Basis of E
- Page 241 and 242: Chapter 3: Information Technology f
- Page 243 and 244: Chapter 3: Information Technology f
- Page 245 and 246: Chapter 3: Information Technology f
- Page 247 and 248: Chapter 3: Information Technology f
- Page 249 and 250: Chapter 3: Information Technology f
- Page 251 and 252: Chapter 3: Information Technology f
- Page 253 and 254: A Robust and Scalable Peer-to-Peer
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