Capability Interaction Graph (CIG)
- Capability Interaction Graph (CIG) is a formal model that represents functional dependencies and potential failure propagation in cyber-physical systems using an ontology-grounded approach.
- It leverages UFO for semantic disambiguation and employs knowledge graphs to connect components, capabilities, and resource flows, facilitating automated reliability analysis.
- The framework serves as an intermediate layer between architectural models and Fault Tree synthesis, enabling multidisciplinary collaboration and traceable fault analysis.
Searching arXiv for the specified paper to ground the article. {"2query2 OR title:\2"Ontology-Grounded Capability Interaction Graphs: From Knowledge Graphs to Fault Trees\"","max_results":5,"sort_by":"submittedDate","sort_order":"descending"} Capability Interaction Graph (CIG) is a formally grounded representation of a cyber-physical system’s functional dependency structure and its potential failure-propagation pathways. In the formulation introduced in "Ontology-Grounded Capability Interaction Graphs: From Knowledge Graphs to Fault Trees" (&&&2query2&&&), CIGs are ontology-driven, grounded in the Unified Foundational Ontology (UFO), and naturally represented as knowledge graphs. They are intended to support reliability modeling in multidisciplinary Cyber-Physical Systems (CPSs), where failures, their cascading effects, and subsystem interactions are often documented incompletely or remain tacit in expert practice. The framework positions CIGs as an intermediate model between architectural knowledge graphs and synthesized Fault Trees, with the explicit goal of enabling automated, semantically grounded reliability analysis.
2id:(Ntagengerwa et al., 18 Jun 2026) OR title:\2. Formal definition and representational scope
A CIG is defined over a finite set of resource types PRESERVED_PLACEHOLDER_2query2, such as “Ink” or “Electricity.” A passenger CIG is a particular instance PRESERVED_PLACEHOLDER_2id:(Ntagengerwa et al., 18 Jun 2026) OR title:\2^ of the type
with a factual CIG written as
In this formulation, contains capabilities, understood as dispositions that inhere in exactly one object; each tuple states that capability , when manifested, consumes each and produces each . denotes functions, treated as atomic events that manifest exactly one capability. There is a partial bijection PRESERVED_PLACEHOLDER_2id:(Ntagengerwa et al., 18 Jun 2026) OR title:\2query2^ such that PRESERVED_PLACEHOLDER_2id:(Ntagengerwa et al., 18 Jun 2026) OR title:\2id:(Ntagengerwa et al., 18 Jun 2026) OR title:\2^ manifests capability PRESERVED_PLACEHOLDER_2id:(Ntagengerwa et al., 18 Jun 2026) OR title:\22^ (&&&2query2&&&).
Faults are given by PRESERVED_PLACEHOLDER_2id:(Ntagengerwa et al., 18 Jun 2026) OR title:\23 and are characterized as modes preventing the manifestation of certain capabilities. The component set is defined as PRESERVED_PLACEHOLDER_2id:(Ntagengerwa et al., 18 Jun 2026) OR title:\24, where a component PRESERVED_PLACEHOLDER_2id:(Ntagengerwa et al., 18 Jun 2026) OR title:\25 carries exactly the capabilities PRESERVED_PLACEHOLDER_2id:(Ntagengerwa et al., 18 Jun 2026) OR title:\26, may manifest exactly the functions PRESERVED_PLACEHOLDER_2id:(Ntagengerwa et al., 18 Jun 2026) OR title:\27, and bear exactly the faults PRESERVED_PLACEHOLDER_2id:(Ntagengerwa et al., 18 Jun 2026) OR title:\28. Channels are represented as PRESERVED_PLACEHOLDER_2id:(Ntagengerwa et al., 18 Jun 2026) OR title:\29 and mediate transport of each accommodated resource. For each channel 2query2^ and resource 2id:(Ntagengerwa et al., 18 Jun 2026) OR title:\2, 2 and 3 are the unique consumption and production capabilities of 4 for 5.
The interface structure is split into output interfaces and input interfaces. Output interfaces are defined by 6, linking component producers to channels; each 7 aggregates the component-capability 8 of 9 and the channel’s 2query2. Input interfaces are defined by 2id:(Ntagengerwa et al., 18 Jun 2026) OR title:\2, linking channels as providers to component consumers analogously. Finally, 2 denotes expectations, where an expectation 3 states that capability 4 is required to be manifested in the current situation.
This organization makes the CIG a dependency model centered on capabilities rather than only on components or signals. A plausible implication is that the framework emphasizes failure semantics at the level of functional provision and resource dependency, which differs from purely structural network descriptions.
2. Ontological grounding in UFO
All CIG elements are grounded in UFO. Components and channels are UFO-endurants, that is, objects. Capabilities and faults are intrinsic moments, specifically dispositions inhering in exactly one bearer 5. Functions, fault activations, and errors are UFO-perdurants, that is, events manifesting dispositions via 6. Interfaces are relators existentially dependent on the participating capabilities (&&&2query2&&&).
The ontology also makes explicit the distinction between fault creation, fault activation, and error propagation. Fault creation is a spontaneous event; fault activation is a triggered error; error propagation is a causal sequence. This is expressed using UFO-B’s notions of situations, triggers, and brings-about, together with the predicates
7
8
9
2query2^
A fault creation over faults 2id:(Ntagengerwa et al., 18 Jun 2026) OR title:\2^ in object 2 is defined as
3
An error for expectation 4 is defined as
5
The significance of this grounding lies in semantic disambiguation. The paper states that UFO grounding disambiguates fault creation, activation, error, and the distinctions among event, situation, and state. This suggests that CIGs are designed not merely as graph encodings of architecture but as semantically typed artifacts intended to preserve explanatory distinctions that are often collapsed in informal reliability models.
3. Construction from CPS architecture and knowledge graphs
CIG construction proceeds from a Knowledge Graph that instantiates a lightweight ontology described as gUFO + CIG schema. The extraction is performed with SPARQL queries over the KG. The paper specifies that the 2query2^ retrieves all components ?α rdf:type :Component, all capabilities ?f :inheresIn ?α, resource types ?r rdf:type :ResourceType, all channels ?c :accommodates ?r, and all input/output interfaces linking ?α, ?c for resource ?r (&&&2query2&&&).
A representative SPARQL fragment is given as:
9
The result set 6 is transformed into an initial CIG 7 by a mapping 8. According to the specification, this mapping collects all capability tuples, function-manifestation, component/capability/fault sets, channel definitions, interface definitions, and an empty initial 9.
The KG representation itself uses gUFO, a lightweight OWL profile of UFO. The classes include Component, Channel, Capability, Fault, Function, ResourceType, InputInterface, OutputInterface, and Expectation. The object properties include gufo:inheresIn, gufo:manifests, :consumes, :produces, :accommodates, :providedBy, and :provides. Example ABox facts include (PSU, rdf:type, Component), (fElec, rdf:type, Capability), (fElec, gufo:inheresIn, PSU), and (fElec, :consumes, Electricity).
Graph-based reasoning via standard OWL/RDFS entailments and SPARQL populates the CIG elements. Situations and events are not represented in the KG; the KG encodes only the static architecture 2query2. This restriction is methodologically important: the architectural model is static, while failure semantics are imposed through the CIG-to-Fault-Tree transformation and the associated interpretation of errors and fault activations.
4. Fault Tree synthesis from CIGs
Given an initial CIG 2id:(Ntagengerwa et al., 18 Jun 2026) OR title:\2, the framework synthesizes a static Fault Tree
2
targeting a top-level capability 3. Here, 4 is the set of Basic Events, each corresponding to fault activation of one capability; 5 is the set of intermediate gates; 6 is the type of each gate; and 7 gives the children of each gate (&&&2query2&&&).
The transformation is specified procedurally:
2query2^
The recursion builds, for each capability node, one OR gate expressing “fault-activation or loss-of-all-resources,” one basic event for its own fault activation, and, for each prerequisite resource 8, one AND gate that requires an error in every minimal provider of 9. The provider chain is described as component-output OR → channel depletion OR → component provider OR → recurse.
The paper further states a failure-semantics preservation result. For each Fault Tree, an evaluation 2query2^ gives whether event 2id:(Ntagengerwa et al., 18 Jun 2026) OR title:\2^ occurs when a set 2 has failed. By induction, for any CIG situation 3 and top-level capability 4,
5
where 6 is the CIG’s structure function, meaning that an error is active across 7, and 8 is the set of basic events corresponding to the capabilities erroneous in 9. Within the confines of the paper, this establishes that the synthesized Fault Tree preserves the relevant failure semantics of the CIG.
5. Running example: print-head subsystem
The running example is a print-head subsystem. In the architecture 2query2, PSD provides Electricity, InkReservoir provides Ink, and both feed PrintHead via the channels wire and tube. The CIG capabilities in 2id:(Ntagengerwa et al., 18 Jun 2026) OR title:\2^ are
2
with expectations
3
and initial faults
4
The constructed CIG diagram is given as:
2id:(Ntagengerwa et al., 18 Jun 2026) OR title:\2^
For the target DepositInk, the synthesized Fault Tree contains an OR gate for DepositInk, a basic event FaultActivation(DepositInk), and an AND gate for “loseElec” AND “loseInk.” The electrical path is represented as FaultActivation(wire-elec) OR FaultActivation(PSU-elec), and the ink path as FaultActivation(tube-ink) OR FaultActivation(InkRes-ink) (&&&2query2&&&).
The qualitative minimal cut sets are stated explicitly as
5
plus the single cut set
6
This example illustrates the stated transformation principle: direct failure of the target capability yields a single basic-event cut set, whereas loss of required resources is captured compositionally through the conjunction of independently disrupted prerequisite paths.
6. Analytical role, benefits, and multidisciplinary significance
The framework is presented as supporting early-stage reliability modeling because CIGs require only functional architecture and resource-flow information, not detailed error models (&&&2query2&&&). It also provides ontological clarity through UFO grounding, traceability because each Fault Tree element maps back to components, capabilities, and interfaces in the KG and thus the system model, and automation because SPARQL queries together with the CIG-to-FT algorithm yield Fault Trees without manual gate placement.
The generated Fault Trees are intended to support both qualitative and quantitative Fault Tree Analysis. The paper states that once a Fault Tree is generated, standard cut-set and probability analysis apply. Interoperability is also emphasized: CIGs absorb heterogeneous modeling languages, including SysML, AADL, and custom KGs, under a common UFO-based ontology. In addition, multidisciplinary collaboration is explicitly identified as a benefit, because systems engineers, software engineers, and reliability experts share a unified semantic layer.
These claims position CIGs as a lightweight but formally precise intermediate model between architectural knowledge graphs and synthesized Fault Trees. A plausible implication is that the method addresses a recurrent integration problem in CPS engineering: architectural models, semantic models, and reliability artifacts are often developed in different notations and by different expert groups. The CIG formalism, as described, is intended to mediate among these layers without requiring detailed stochastic failure models at the initial stage.
7. Conceptual boundaries and common points of confusion
Several boundaries of the framework are explicit in the formulation. First, the KG encodes only the static architecture 7; situations and events are not represented in the KG. Reliability semantics therefore do not arise solely from RDF/OWL encoding, but from the combination of ontological grounding, graph extraction, and Fault Tree synthesis. Second, the synthesized artifact is a static Fault Tree. The paper does not present the CIG itself as a substitute for Fault Tree Analysis; rather, CIGs provide the semantically grounded dependency model from which Fault Trees are generated.
A further point concerns the role of expectations. The set 8 does not merely annotate desired functions informally; it denotes that a capability is required to be manifested in the current situation. This is central to the definition of error, which is framed in terms of whether an expectation is met. Another possible misunderstanding is to treat channels as passive connections only. In the CIG formalization, channels have their own accommodated resources and associated consumption and production capabilities, and channel-level failures appear explicitly in the synthesized Fault Tree.
Finally, the framework is not described as eliminating the need for domain expertise. Rather, it reduces complexity by leveraging CIGs and knowledge graphs, while providing a common semantic representation across engineering domains and supporting automated generation of reliability models. This suggests a division of labor in which expert architectural knowledge is formalized once in a KG and then reused for downstream reliability analysis through ontology-grounded transformation.