In order to constrain the emerging terms within the developing heavyweight ontology logical rules were required. These rules would have to constrain the terms within the combined contexts of both the MI systems domain and the requirements for interoperability.
The research described in Section 5.5 which resulted in the definition of MI generated some basic defining statements which could be used to help define logic and relationships later in the process. These were relatively loose descriptive statements that proved to be useful in creating a clear MI definition but required a level of interpretation to generate logic and relationships as described in Section 6.6.
Based on the findings from the literature review and industrial investigation (see Chapters 2 and 3) the challenges to systems interoperability could be grouped into ‘themes’ and these themes were then be used to identify constraining logic, to which a type or instance within the ontology must conform if it is to meet the requirements for interoperability. The logic themes and example logic are shown in Figure 6-38:
Figure 6-38 - Logic development themes developed from the challenges to interoperability research
The next approach was to focus the subject matter experts on the purpose of the ontology and list rules and relationships between individual terms using the UML taxonomies as a prompt. The development of these rules was structured around the key themes previously
identified as the challenges to system interoperability. This work resulted in the following statements:
Each data instance has a technical authority level
Each data instance has an operational authority level
Decisions about systems can only be made by super users or administrators
Non standard systems specifications require manager and super user approval
A Person has a technical authority level
A Person has an operational authority level
If a person’s operational authority level is less than the data authority level they cannot access the data
If a person’s technical authority level is less than the data authority level they cannot access the data
Having technical authority does not give a person operational authority
A system should use a standard data structure
Anything with obsolete or deleted status should not be used
For something to be approved, all data must be proven or approved.
A change decision makes proven data unproven.
If data is not approved it is be default unapproved
The use of unapproved data within a system renders the system output unapproved
Users or employees cannot change unproven to proven or unapproved to approved
Outside of its validity timescale data becomes unapproved
Equipment maintenance requires maintenance data
Output data should must have a timestamp
Finish data Timestamps cannot precede a start timestamp.
Increasing a person’s authority requires some sort of training
For a person to work with a system there must be a HMI
For two or more systems to work together there must be a system-system interface defined
For 2 systems to measure the same metric they must use the same data types.
For decisions to be consistent across people and systems the same data or metrics must be used.
A system requires sustainment processes to remain consistent.
People require training to remain consistent
The durations between training to maintain person consistency must be defined.
Maintenance intervals for a equipment must be defined
The consistency of people and systems should be monitored.
Metrics must be defined for any form of monitoring
Targets must be defined for any form of monitoring.
Reactions must be defined for any form of monitoring
A system must be described by a functional and non functional spec
If a system uses IT there must be an IT spec.
Proactive feedback uses input data
Reactive feedback uses output data
Responses require output data
Using non standard data structures requires super user authority
Specifications must be approved by people with leaders and super users authority or higher
System inputs, outputs must be specified for a system
System resource and constraints should be specified for a system
Metric targets have a validity timescale
Metric data has a validity timescale
A system has a data type if it is an input, output, resource or constraint
If a system outputs a program it is a programming system
If a system has data inputs but no data outputs it is a data storage system
If a system is the only store of a data type it is an archiving system
Data should not be stored in 2 archiving systems
If data is stored in 2 archiving systems one must be declared the authoritative data store
Data should have a data retention category (mandatory/ non mandatory)
Data should have and export control category (export controlled/ non export controlled)
Data should have a security category (public, private, secret, top secret)
systems should have a security, export control and data retention category
If an system doesn’t have a security category if should be set to public
If an system doesn’t have an export control category it should be set to non export controlled
If an system doesn’t have a data retention category if should be set to non mandatory
systems that have security category of public can only input or output public category data
systems that have security category of private can only input or output public or private category data
systems that have security category of secret can only input or output public, private or secret category data
systems that have security category of top secret can only input or output public, private, secret or top secret category data
systems with an export control category of non export control can only input or output non export control data
systems with an data retention category of non mandatory control can only input or output non mandatory retention data
If a data item is the input of one system and the output of another these systems are series associated
If a system outputs data to another system it is an input for that other system
A system functional spec must define a performance metric and metric target
Systems that share the same input, outputs resources or constraints are parallel associated
If a system outputs data that is not input into it, it is the data source for that data The term pool, taxonomy and relationship development the logic development were all iterative and interlinked, with developments in one area requiring a form of regression
assessment to ensure all logic and relationships still held true and comply to the constraining logic. This logic was also checked against the BPMNs (representing real systems and
process) to ensure the correlation with reality. At this stage this was a manual activity, and the complexity due to the number of terms and relationships was highlighted by the number of issues that would be highlighted during the ontology coding activity, where these checks were carried out by the software in a very rigorous manner.