Effective capability definition, development, acquisition and integration require the ability to not only reason about what operational outcomes need to be achieved but to reason about what courses of action could be performed (what needs to be done), to what levels of performance (how well do they need to be performed), and under what conditions (in what operational environment and state - when - do they need to be performed) to achieve those outcomes.
As engineers, our mission is to design and assure system solutions (solutions integrating technology, people, organisations, processes, etc.) to optimise the achievement of positive mission outcomes while reducing risks that threaten those outcomes.
What we need to be able to model
We must start with a high-fidelity understanding of the behaviour we are trying to design into the solution. We need a deep, accurate and shared understanding of that behaviour. We need a description of the deterministic and probabilistic courses of action and interaction possible under certain antecedent conditions and their likely consequences. To enable mapping of enabling solution elements to those courses of action, those courses of action must be defined with enough fidelity to answer questions of what is being done when (and to some extent by whom/what); what are the causal and temporal relationships between the things being done; what resources are being exchanged and what is being done with those resources; and how are those aspects interrelated.
Properties required of those models
There are two critical properties that those models must possess to optimise and assure system solutions:
The models of behaviour must be valid. Currently, validation is performed by human subject matter experts. So, the models must be human-readable and lend themselves to scenario-based walkthroughs, and
The models must be formal enough to support mapping and reasoning about enablers, fundamental inputs to capability, and their predicted and observable performance and impact on the outcome.
The Legacy of Prof. Geoff Dromey
The Behaviour Modelling Language
The Behaviour Models within Kompozition are not built around the behavioural/interaction views defined within the UML/SysML. These UML/SysML views are disparate. They require a large effort to keep consistent, let alone integrate, and even more effort is required to maintain consistency between behavioural views and the associated compositional and structural views. Walkthroughs, particularly walkthroughs with non-engineer subject matter experts, are ineffective. Maintenance is difficult. UML/SysML views do look good in PPT decks, though.
Kompozition is built around the Behaviour Modelling Language (BML) developed by the late Prof. Geoff Dromey as the language behind the Behaviour Engineering (bE) methodology in the late 19990s and early 2000s. The bE methodology and the BML were successfully applied in industry to create high-fidelity models of large systems in the defence, aerospace, transport and government sectors to enable a deep, accurate and shared understanding of the needs of those systems and the uncertainty and risks associated with them.
The Behaviour Modelling Language allows the constructive (iterative and incremental) development of very large, high-fidelity integrated Behaviour Trees that are human-readable and proven effective for validation, at the same time as being formal enough to be useful for deriving and justifying design and for supporting simulation and execution.
The Behaviour Modelling Language is expressive enough and general enough to capture behaviour at the broadest operational/contextual level, down to the level of defining algorithms.
As opposed to maintaining consistency between behavioural, compositional and structural views, the BML representation of behaviour contains sufficient information to synthesise the compositional and structural information required of that behaviour - a significant chunk of the architecture at the model's level of detail.
For example, once we have defined behaviour using the BML, the Kompozition machine learning and heuristic modules can deduce what resources, information and data are required in the performance of that behaviour; what relationships between these things are established, broken or tested during the behaviour; what activities/functions are performed by what actors; how those actors interact and interface; what is exchanged between them; … Kompozition can automatically link the behavioural, compositional and structural aspects of the problem space (and provide the ability to architects and engineers to modify and refine that synthesised information).
If we create a Behaviour Tree at the operational level of detail in Kompozition, then Kompozition can automatically synthesise and link a very large proportion of the operational/functional architecture and functional requirements based entirely on the definition of the problem. This synthesis of digital threads of information within the Kompozition knowledge graph greatly reduces the effort and risk in MBSE/DME endeavours.
The behavioural, compositional and structural information in a Kompozition model of a problem space, provides “hooks” to be linked to the digital description of a solution to that problem to whatever level of depth is required, with a record of all verification and validation qualifying that solution (definition, trace and results), enabling and end-to-end model-based approach to capability definition, acquisition and integration that could also be used for mapping real-world observables to operational intent post-acceptance into service.
