ontology-driven-cps-dataspace

star 2

Ontology-driven dataspace approach for reproducible test annotation in Cyber-Physical Energy Systems using three-viewpoint ontology framework (HTD-O, SCM-O, OPMW).

hiyenwong By hiyenwong schedule Updated 6/3/2026
play_arrow Run Skill in Manus View GitHub

name: ontology-driven-cps-dataspace version: 1.0.0 description: Ontology-driven dataspace approach for reproducible test annotation in Cyber-Physical Energy Systems using three-viewpoint ontology framework (HTD-O, SCM-O, OPMW). category: systems-engineering tags: [cyber-physical systems, ontology, reproducibility, dataspace, energy systems, test annotation, provenance, SysML] source: arXiv:2604.19686v1 authors: [Kai Heussen, et al.] date: 2026-04-21

Ontology-Driven Dataspace for Reproducible CPS Energy Systems Testing

Overview

A three-viewpoint ontology framework for reproducible test annotation in Cyber-Physical Energy Systems (CPES). Uses dataspaces to enable cross-laboratory test reproduction, standardized metadata capture, and full provenance tracking. Demonstrated via PV inverter testing across Irish and Swiss laboratories.

Three-Viewpoint Ontology Architecture

┌─────────────────────────────────────────────────────┐
│                  DATASPACE LAYER                     │
│         (RDF/OWL descriptions, SPARQL queries)       │
├───────────────┬───────────────┬─────────────────────┤
│    HTD-O      │    SCM-O      │       OPMW          │
│  (Testing     │  (System      │    (Workflow &      │
│   Domain)     │   Config)     │    Provenance)      │
├───────────────┼───────────────┼─────────────────────┤
│ Test types    │ Components    │ Workflow spec        │
│ Test steps    │ Connections   │ Execution log        │
│ Acceptance    │ Topology      │ Data lineage         │
│ criteria      │ Parameters    │ Provenance chain     │
└───────────────┴───────────────┴─────────────────────┘

Viewpoint 1: HTD-O (Holistic Test Description Ontology)

Purpose: Describe WHAT is being tested and HOW.

  • Aligned with EXPO (Experiment Ontology)
  • Key concepts:
    • TestObjective — what the test aims to verify
    • TestProcedure — sequence of test steps
    • TestInput — stimuli applied to system under test
    • ExpectedOutcome — acceptance criteria
    • ActualOutcome — measured results
class HTDontology:
    """Holistic Test Description Ontology entities."""
    
    NAMESPACE = "http://ontology.cps-energy.org/htd#"
    
    CLASSES = [
        "TestObjective",
        "TestProcedure", 
        "TestStep",
        "TestInput",
        "ExpectedOutcome",
        "ActualOutcome",
        "EquipmentUnderTest",
        "TestEnvironment"
    ]
    
    PROPERTIES = [
        "hasObjective",
        "hasProcedure",
        "hasStep",
        "hasInput",
        "hasExpectedOutcome",
        "hasActualOutcome",
        "testsEquipment",
        "inEnvironment"
    ]

Viewpoint 2: SCM-O (System Configuration Model Ontology)

Purpose: Describe the SYSTEM under test (topology + parameters).

  • Lightweight topology-oriented modeling
  • Aligns with: CIM (Common Information Model), IEC 61850-6 SCL, SysML, SEAS, SAREF4SYST
  • Key concepts:
    • Component — physical or digital entity
    • Connection — links between components
    • Parameter — configurable values
    • Topology — overall system structure
class SCMOntology:
    """System Configuration Model Ontology entities."""
    
    NAMESPACE = "http://ontology.cps-energy.org/scm#"
    
    CLASSES = [
        "Component",
        "Connection", 
        "Parameter",
        "Topology",
        "ElectricalComponent",
        "ControlSystem",
        "Sensor",
        "Actuator"
    ]
    
    # Aligns with IEC 61850-6 SCL for substation configuration
    # Aligns with CIM for power system modeling
    # Aligns with SysML for systems engineering

Viewpoint 3: OPMW (Ontology for Planning and Managing Workflows)

Purpose: Track HOW the test was executed (provenance).

  • Extends W3C PROV-O standard
  • Separates workflow specification from workflow execution
  • Key concepts:
    • WorkflowTemplate — planned process
    • WorkflowExecution — actual execution record
    • DataProduct — input/output data with lineage
    • StepExecution — individual step record with timestamps
class OPMWOntology:
    """Workflow and Provenance Ontology entities."""
    
    NAMESPACE = "http://ontology.cps-energy.org/opmw#"
    
    CLASSES = [
        "WorkflowTemplate",
        "WorkflowExecution",
        "DataProduct",
        "StepExecution",
        "Agent",
        "Activity"
    ]
    
    # Extends W3C PROV-O
    # Key: separation of specification vs execution

Dataspace Implementation Pattern

Step 1: Annotate Test with Ontologies

from rdflib import Graph, Namespace, Literal, RDF

HTD = Namespace("http://ontology.cps-energy.org/htd#")
SCM = Namespace("http://ontology.cps-energy.org/scm#")
OPMW = Namespace("http://ontology.cps-energy.org/opmw#")

def annotate_test(test_config, system_config, execution_log):
    g = Graph()
    g.bind("htd", HTD)
    g.bind("scm", SCM)
    g.bind("opmw", OPMW)
    
    # Add test description (HTD-O)
    test_uri = URIRef(f"urn:test:{test_config['id']}")
    g.add((test_uri, RDF.type, HTD.TestProcedure))
    for step in test_config['steps']:
        step_uri = URIRef(f"urn:step:{step['id']}")
        g.add((test_uri, HTD.hasStep, step_uri))
        g.add((step_uri, RDF.type, HTD.TestStep))
    
    # Add system configuration (SCM-O)
    system_uri = URIRef(f"urn:system:{system_config['id']}")
    g.add((system_uri, RDF.type, SCM.Topology))
    for comp in system_config['components']:
        comp_uri = URIRef(f"urn:component:{comp['id']}")
        g.add((system_uri, SCM.hasComponent, comp_uri))
    
    # Add execution provenance (OPMW)
    exec_uri = URIRef(f"urn:execution:{execution_log['id']}")
    g.add((exec_uri, RDF.type, OPMW.WorkflowExecution))
    g.add((exec_uri, OPMW.realizes, test_uri))
    
    return g

Step 2: Publish to Dataspace

def publish_to_dataspace(graph, dataspace_endpoint):
    """Publish annotated test description to dataspace."""
    serialized = graph.serialize(format="turtle")
    # POST to dataspace endpoint
    response = requests.post(
        f"{dataspace_endpoint}/publish",
        data=serialized,
        headers={"Content-Type": "text/turtle"}
    )
    return response.status_code == 200

Step 3: Cross-Laboratory Reproduction Query

def find_reproducible_tests(dataspace_endpoint, test_type):
    """Query dataspace for tests that can be reproduced."""
    query = f"""
    PREFIX htd: <http://ontology.cps-energy.org/htd#>
    PREFIX scm: <http://ontology.cps-energy.org/scm#>
    PREFIX opmw: <http://ontology.cps-energy.org/opmw#>
    
    SELECT ?test ?system ?execution ?lab
    WHERE {{
        ?test a htd:TestProcedure ;
              htd:hasObjective ?obj .
        ?obj a htd:{test_type} .
        ?execution opmw:realizes ?test ;
                   opmw:executedBy ?lab .
        ?system scm:usedIn ?test .
    }}
    """
    # Execute SPARQL query against dataspace
    return execute_sparql(dataspace_endpoint, query)

Cross-Laboratory Reproduction Methodology

Identified Reproduction Gaps (UCD Ireland ↔ ZHAW Switzerland)

  1. Impedance characterization: Grid simulator impedance differs between labs
  2. Metadata capture: Inconsistent recording of environmental conditions
  3. Event logging: Timestamp synchronization and event annotation vary
  4. Parameter mapping: Different naming conventions for equivalent parameters

Resolution Strategy

Lab A Test → HTD-O/SCM-O/OPMW annotation → Dataspace publication
                                                    ↓
Lab B Query → Retrieve full test specification → SCM-O system mapping
                                                    ↓
Lab B Execute → OPMW provenance tracking → Compare results

Application Domains

  • Power electronics testing (PV inverters, wind turbines)
  • Smart grid equipment certification
  • EV charging system compliance testing
  • Building energy management system verification
  • Any CPS domain requiring reproducible testing

Key Benefits

  1. Reproducibility: Full provenance chain from test specification to execution
  2. Interoperability: Ontology alignment with CIM, IEC 61850, SysML, PROV-O
  3. Scalability: Dataspace pattern supports federated, decentralized test databases
  4. Traceability: Every test result traceable to specific equipment, configuration, and conditions

Pitfalls & Caveats

  1. Ontology alignment effort: Mapping between HTD-O/SCM-O and domain standards requires expertise
  2. Metadata overhead: Comprehensive annotation is time-consuming; automate where possible
  3. Dataspace maturity: Dataspace pattern is relatively new; tooling still evolving
  4. Cross-lab calibration: Even with perfect annotations, physical differences require careful interpretation
  5. Scalability of RDF: Large test datasets may require triple store optimization

References

  • arXiv:2604.19686v1 — Towards Reproducible Test Annotation for Cyber-Physical Energy Systems using Ontology-driven Dataspaces (Heussen et al., 2026)
  • OSMSES 2026 conference paper
  • Zenodo dataset: doi:10.5281/zenodo.18868542
  • Related: W3C PROV-O, IEC 61850-6, CIM (IEC 61970), SysML
Install via CLI
npx skills add https://github.com/hiyenwong/ai_collection --skill ontology-driven-cps-dataspace
Repository Details
star Stars 2
call_split Forks 0
navigation Branch main
article Path SKILL.md
Occupations
Physical Scientists all other
More from Creator
hiyenwong
hiyenwong Explore all skills →