Engineering Executable Enterprise Architecture

Integrating UML/SysML, Sparx Enterprise Architect 15.2, BDD, DDD, Gherkin, Cucumber and AI-Assisted Engineering for Cyber-Physical Systems

A Research White Paper

Prepared by: IAS Research (IAS-Research.com)
Implementation and commercialization partner: KeenComputer.com
Location: Winnipeg, Manitoba, Canada
Date: October 2026

Abstract

Engineering organizations increasingly develop products in which embedded firmware, application software, artificial intelligence, electronic hardware, control systems and cloud services must operate as one coherent system. Yet requirements, architecture models, source code, simulation models and verification evidence frequently remain separated across tools and teams. This fragmentation increases the cost of change, weakens traceability and delays the discovery of architectural defects.

This paper proposes a repository-centred, executable approach to Enterprise Architecture (EA) and Model-Based Systems Engineering (MBSE). It integrates UML and SysML modelling in Sparx Enterprise Architect 15.2, Domain-Driven Design (DDD), Behaviour-Driven Development (BDD), Gherkin specifications, Cucumber automation, simulation, continuous integration and AI-assisted development using Claude Code or comparable coding assistants.

Two representative cyber-physical engineering projects illustrate the method: OBD-AI, a vehicle diagnostics and retrieval-augmented generation (RAG) platform, and a 1 kW single-phase smart inverter for Distributed Energy Resources (DER). The first illustrates the integration of vehicle telemetry, diagnostics, knowledge retrieval and embedded computing. The second demonstrates the separation of power conversion, grid support, supervision and protection responsibilities.

The proposed architecture establishes a continuous traceability chain from stakeholder need to requirement, model element, behavioural scenario, implementation, verification result and engineering evidence. It also proposes a multi-target testing strategy in which behavioural specifications can coordinate software tests, SystemC Transaction-Level Modelling (TLM), MATLAB/Simulink simulations, Software-in-the-Loop (SIL), Processor-in-the-Loop (PIL) and Hardware-in-the-Loop (HIL) testing.

The strategic contribution is a practical framework for small and medium-sized engineering enterprises seeking the discipline of enterprise-scale engineering without unnecessarily burdensome processes. IAS-Research.com can lead architecture, research and technical assurance, while KeenComputer.com can implement, integrate, deploy and operate the resulting solutions.

This paper presents a proposed methodology and implementation roadmap, not a report of experimentally validated productivity improvements or completed certification. Its recommendations must be evaluated through controlled pilots, domain-expert review and appropriate engineering verification.

Keywords: Enterprise Architecture, Model-Based Systems Engineering, UML, SysML, Sparx Enterprise Architect 15.2, Domain-Driven Design, Behaviour-Driven Development, Gherkin, Cucumber, Claude Code, AI-assisted software engineering, hardware/software co-design, SystemC TLM-2.0, OBD-II, RAG, smart inverter, DER, DevOps, continuous verification.

Executive Summary

The engineering problem

A cyber-physical product is rarely designed in a single tool. Requirements may reside in Sparx Enterprise Architect, behavioural expectations in documents, implementation in Git repositories, control algorithms in MATLAB/Simulink and test results in separate reports.

When a requirement changes, engineering teams must determine which architecture elements, interfaces, software modules, simulation assumptions and verification activities are affected. If these relationships are informal, impact analysis becomes dependent on individual knowledge.

The proposed solution is to make engineering artefacts traceable, version-controlled and testable.

The proposed framework

The framework integrates six complementary disciplines:

  1. Enterprise Architecture: connects business objectives, product capabilities, systems and technology.
  2. UML/SysML and MBSE: represents requirements, structure, interfaces, behaviour and hardware/software allocation.
  3. DDD: establishes bounded contexts, domain ownership and a shared engineering vocabulary.
  4. BDD and Gherkin: translates requirements into observable, reviewable behavioural scenarios.
  5. Cucumber and automated verification: executes approved scenarios against appropriate implementations and models.
  6. AI-assisted engineering and DevOps: accelerates drafting, scaffolding, consistency checking and traceability maintenance under controlled human review.

Sparx Enterprise Architect remains the governed modelling environment. Git stores approved exports, textual specifications, architecture decisions, test code and supporting scripts. Automated checks identify inconsistencies, while engineers retain authority over architecture, safety, protection settings and certification evidence.

Two complementary engineering applications

Dimension

OBD-AI

Smart inverter DER

Primary engineering concern

Vehicle diagnostics and evidence-grounded advisory

Grid-connected power conversion and grid-support behaviour

Architectural focus

Embedded device, mobile application, AI server

Power stage, controller, grid interface and protection

Domain decomposition

Five bounded contexts

Six proposed bounded contexts

Simulation strategy

Software reference model and SystemC TLM-2.0

MATLAB/Simulink and control-system simulations

Hardware integration

Puck device, vehicle-bus simulator and optional FPGA

MCU/FPGA, real-time interfaces and HIL

Critical quality concern

Correct decoding, source-grounded guidance and safe handling of missing evidence

Protection integrity, grid-code conformance and deterministic control

Expected business value

The method is intended to improve:

  • Change-impact analysis and requirement traceability.
  • Early identification of interface and architectural defects.
  • Consistency between specifications, models and implementations.
  • Reuse of test scenarios across development stages.
  • Governance of AI-generated engineering artefacts.
  • Repeatability of technical reviews and handovers.

These benefits are hypotheses to measure, not quantified results established by this paper.

1. Introduction

1.1 Background

Modern engineering is increasingly software-defined. Vehicles combine embedded electronics, network protocols, diagnostics, mobile applications and cloud-based intelligence. Distributed energy systems combine power electronics, digital control, communications, cybersecurity and grid-interconnection requirements.

Such products are cyber-physical systems: software decisions interact with physical processes whose timing, energy, safety and environmental constraints cannot be understood through source-code inspection alone.

Traditional document-driven processes can create a disconnect between the formal architecture and the artefacts used to build and test the product. A diagram may show an interface that is absent from the code. A requirement may lack a measurable acceptance criterion. A test may pass without adequately verifying the intended behaviour.

The proposed approach treats architecture as a maintained set of related engineering artefacts rather than a static document.

1.2 Research objectives

This paper addresses five questions:

  1. How can UML/SysML models in Sparx Enterprise Architect remain aligned with behavioural specifications and implementation?
  2. How can DDD and BDD complement one another in enterprise and system architecture?
  3. How can AI coding assistants accelerate engineering without becoming uncontrolled sources of architectural decisions?
  4. How can the same behavioural intent be checked across software, simulation and hardware?
  5. How can IAS-Research.com and KeenComputer.com package the method into a repeatable engineering service for SMEs?

1.3 Scope and limitations

The method focuses on architecture governance, behavioural specification, traceability, hardware/software co-design and AI-assisted development. It does not replace detailed circuit analysis, control-system stability analysis, formal verification, cybersecurity assessment, vehicle-specific diagnostic validation or certification.

It also does not assume that every Gherkin scenario can be executed identically at every abstraction level. Continuous-time dynamics, numerical precision, real-time scheduling and hardware effects require specialised verification environments.

2. Conceptual Foundation

2.1 Enterprise Architecture

Enterprise Architecture connects organizational objectives with business capabilities, applications, information and technology. Frameworks such as TOGAF and viewpoints expressed through ArchiMate can help communicate these relationships.

For engineering organizations, EA should connect strategic outcomes to product architecture, technical decisions, engineering processes and operational responsibilities.

For example, the business objective of reducing vehicle diagnostic time must connect to the OBD-AI diagnostic workflow, source quality, mobile application, retrieval service and measurable diagnostic outcomes.

Similarly, the objective of supporting grid-connected DERs must connect to inverter functions, grid-interconnection profiles, protection behaviour and verification evidence.

2.2 UML, SysML and MBSE

UML provides views for software structure and behaviour, including class, component, sequence, activity and state-machine diagrams.

SysML extends systems modelling concepts to multidisciplinary engineering, including requirements, system structure, interfaces, parametric relationships and verification.

Sparx Enterprise Architect 15.2 can serve as the central repository for requirements, model elements, relationships and diagrams. For this proposed workflow, the team should export selected model data to version-controlled formats such as XMI or CSV.

The distinction is important: an exported model is a controlled representation of selected architecture data, not necessarily a complete or lossless substitute for the native modelling repository.

Recommended modelling views include:

  • Context and stakeholder views.
  • Requirements and traceability diagrams.
  • Use-case diagrams.
  • Component and deployment diagrams.
  • Sequence and activity diagrams.
  • Domain class models.
  • State machines for lifecycle-dependent behaviour.
  • Hardware/software allocation views.
  • Verification and validation relationships.

2.3 Domain-Driven Design

DDD organizes software around a domain model and a ubiquitous language shared by domain experts and developers.

A bounded context establishes where a particular model and vocabulary are valid. Context maps explain how those contexts collaborate through defined relationships and interfaces.

This is especially useful in systems combining physical measurements, diagnostic interpretations, AI-generated explanations and operational management. A vehicle signal, a diagnostic trouble code and a repair recommendation are related, but they are not the same domain concept.

Likewise, a measured grid voltage, a grid-support command and a protection trip are different concepts with different responsibilities.

Bounded contexts help isolate changes, clarify ownership and reduce the propagation of domain-specific assumptions.

2.4 Behaviour-Driven Development

BDD begins with examples of expected behaviour rather than implementation details.

Gherkin expresses these examples through constructs such as Feature, Scenario, Scenario Outline, Given, When, Then and tags.

Cucumber connects Gherkin steps to executable step definitions. Depending on the implementation language, comparable approaches can be implemented using Cucumber-JVM, Python-based BDD tooling or other compatible test frameworks.

A useful behavioural specification expresses:

  • The relevant preconditions.
  • The event or action being considered.
  • The observable result.
  • The applicable requirement identifier.
  • The verification level and any relevant safety classification.

A scenario should describe behaviour rather than reproduce a sequence of user-interface clicks. Its assertions must be meaningful enough to detect an incorrect implementation.

2.5 AI-assisted engineering

An agentic coding assistant such as Claude Code can help draft scenarios, generate test scaffolding, inspect repository relationships, propose model deltas and interpret build failures.

However, generated artefacts remain proposals until reviewed and verified. The assistant should operate under explicit repository instructions, restricted permissions and deterministic automated checks.

AI assistance is most useful when the task has clear boundaries and mechanically verifiable outputs. It is less suitable as an independent authority for safety claims, regulatory interpretation, protection settings or architectural decisions with major consequences.

3. Proposed Reference Architecture

3.1 Architecture overview

The method creates a controlled relationship between modelling, specification, implementation and evidence.

Business Objectives and Stakeholder Needs | v Enterprise Architecture / MBSE Sparx Enterprise Architect | v Requirements and Use Cases | v DDD Contexts and Glossaries | v Gherkin Behavioural Features | v Cucumber / Test Adapters | +----------+----------+ | | | v v v Software Simulation HIL / FPGA Tests and SIL or Target | | | +----------+----------+ | v Verification Results and Evidence | v Human Review and Approval | v Governed Architecture Baseline

The diagram is a logical workflow, not a claim that one tool automatically implements every integration. Adapters, export scripts and traceability checks must be developed and validated.

3.2 The repository as an engineering integration layer

A recommended repository structure is:

enterprise-architecture/ ├── CLAUDE.md ├── docs/ │ ├── adr/ │ ├── context-map.md │ ├── requirements/ │ ├── glossary/ │ ├── verification/ │ └── security/ ├── model/ │ ├── ea/ │ ├── simulink/ │ └── systemc/ ├── features/ │ ├── telemetry/ │ ├── diagnostics/ │ ├── knowledge/ │ ├── grid-support/ │ └── protection/ ├── steps/ │ ├── python/ │ └── java/ ├── adapters/ │ ├── software/ │ ├── systemc/ │ ├── simulink/ │ └── hil/ ├── tests/ ├── tools/ │ └── trace_check.py └── .claude/ ├── commands/ ├── agents/ └── settings.json

The exact structure should reflect the selected languages, test framework and project size. Separate project repositories may be preferable where access control, safety governance or release independence requires them.

3.3 Traceability identifiers

Every requirement and testable behaviour should have a stable identifier.

A proposed chain is:

NEED-001 → REQ-DIAG-012 → UC-DIAG-001 → SC-DIAG-003 → TEST-DIAG-003 → EVID-DIAG-003

Each identifier represents a distinct artefact:

  • NEED: stakeholder need.
  • REQ: system or software requirement.
  • UC: use case.
  • SC: behavioural scenario.
  • TEST: executable test or test configuration.
  • EVID: execution record and associated evidence.

Model elements should have stable identifiers as well. The mapping between identifiers and Sparx EA GUIDs or other repository keys must be defined and maintained.

A traceability checker should identify missing links, unknown identifiers, duplicate IDs and unbound scenarios. A complete chain is not proof of correctness, but an incomplete chain is a clear governance gap.

3.4 Synchronization with Sparx Enterprise Architect

The recommended approach uses deliberate, reviewable exchanges:

  1. Export approved requirements, domain classes and relevant relationships from Sparx EA.
  2. Commit the exports to the repository with baseline metadata.
  3. Generate proposed changes to features, traceability records or model data.
  4. Review the proposed changes against existing model content.
  5. Import accepted changes into a working EA model.
  6. Review the diagrams and relationships before establishing a new baseline.

The assistant should not directly modify protected model exports or certification evidence. This prevents an apparently successful text edit from silently damaging the authoritative model.

4. Integrating DDD, BDD and UML/SysML

4.1 Different methods, complementary responsibilities

These techniques should not be treated as substitutes for one another.

Technique

Primary question

Principal artefact

EA

How does the engineering solution support business and organizational goals?

Architecture viewpoints

UML/SysML

What is the system, how is it structured, and how does it behave?

Models and diagrams

DDD

Where do domain concepts, rules and responsibilities belong?

Bounded contexts, context maps and glossaries

BDD

What observable behaviour is required?

Gherkin scenarios

Cucumber

Does the implementation satisfy the specified examples?

Executable tests

Simulation and HIL

Does the design behave acceptably under relevant dynamic and physical conditions?

Simulation results and hardware test evidence

AI assistant

How can drafting and consistency work be accelerated?

Proposed artefacts and reviewed changes

4.2 From mind map to executable use case

The recommended workflow is:

  1. Identify stakeholders, actors, goals, external systems and constraints.
  2. Group related domain responsibilities into candidate bounded contexts.
  3. Establish the context map and initial glossary.
  4. Define a use-case brief with actor, trigger, preconditions and expected outcome.
  5. Draft Gherkin scenarios using the approved vocabulary.
  6. Review the scenarios with a domain expert, developer and tester.
  7. Bind the scenarios to executable steps and meaningful assertions.
  8. Link approved scenarios to requirements and model elements.
  9. Run the appropriate tests and retain results.
  10. Update the architecture baseline after review.

This sequence keeps the behavioural specification connected to the architecture without requiring every detail to be decided before useful examples can be written.

4.3 Example requirement-to-test mapping

Consider the requirement that OBD-AI must not fabricate diagnostic information when the vehicle does not respond.

The requirement is allocated to the Diagnostics context. The use case describes reading diagnostic trouble codes. The scenario specifies the no-response condition, the request and the expected outcome. The implementation is then tested against that outcome.

The resulting trace should allow an engineer to answer:

  • Which stakeholder need justifies this requirement?
  • Which architecture element implements the behaviour?
  • Which scenarios verify it?
  • Which test configuration was used?
  • What happened during the most recent approved run?
  • Who reviewed the result?

This is the practical value of executable architecture: the relationships can be inspected and partially checked by tools rather than reconstructed manually during a review.

5. AI-Assisted Engineering with Claude Code

5.1 Operating principles

The AI assistant should be treated as a constrained engineering collaborator.

The project instructions file, CLAUDE.md, should define:

  • Project purpose and architecture boundaries.
  • Approved terminology and glossary locations.
  • Repository structure and coding conventions.
  • Build, lint, simulation and test commands.
  • Protected directories and prohibited operations.
  • Required review and approval points.
  • Rules for handling external documents and confidential data.

Project-specific behaviour must be checked against the current Claude Code documentation because capabilities and configuration details may change.

5.2 Recommended reusable commands

The team can establish reusable commands or skills for common engineering activities:

  • /usecase — draft a Gherkin feature from an approved use-case brief.
  • /scenarios — propose boundary, failure and degraded-mode cases.
  • /steps — generate step-definition scaffolding.
  • /ctxcheck — check terminology and context-boundary compliance.
  • /trace — execute the traceability checker and report missing links.
  • /adr — draft an Architecture Decision Record with alternatives and consequences.

These are proposed project conventions, not guaranteed built-in commands. They must be implemented using the assistant's supported extension mechanisms.

5.3 Specialized review roles

Where supported, separate review agents or workflows can be assigned narrow responsibilities:

Architecture reviewer: checks consistency with approved architecture decisions and context maps.

Requirements analyst: identifies ambiguity, conflicting assumptions and untestable requirements.

Verification reviewer: checks that tests contain meaningful assertions and exercise relevant failure conditions.

Safety reviewer: flags missing or weakened protection and safety-related scenarios.

A generated review is not an independent safety certification. High-consequence decisions must be reviewed by accountable, appropriately qualified engineers.

5.4 Deterministic controls

Prompts alone cannot guarantee compliance. Mechanical checks should enforce rules wherever feasible.

Examples include:

  • Gherkin syntax and style linting.
  • Automated unit and integration tests.
  • Validation of requirement and scenario identifiers.
  • Detection of undefined step definitions.
  • Build and simulation checks.
  • Protected-path permissions.
  • Mandatory review for changes to safety-tagged scenarios.
  • Audit logs and approved version-control changes.

A pre-commit hook and continuous integration pipeline should execute the relevant checks. A failure should block the applicable merge or release until resolved or formally dispositioned.

6. Case Study A: OBD-AI Vehicle Diagnostics Platform

6.1 System overview

OBD-AI combines three principal system elements:

  1. An embedded Puck device connected to a vehicle diagnostic interface.
  2. A mobile application used to request and present diagnostic information.
  3. An AI server that retrieves relevant service-manual passages and generates explanations or repair guidance.

The intended knowledge base spans internal-combustion, hybrid and electric vehicles. Its reliability depends on source quality, vehicle applicability, correct interpretation and the ability to distinguish supported conclusions from missing evidence.

6.2 DDD decomposition

The proposed five bounded contexts are:

Vehicle Telemetry: acquires and normalizes vehicle signals. Typical domain concepts include Vehicle, Session and SignalFrame.

Diagnostics: reads, decodes and classifies diagnostic trouble codes. Typical concepts include DTC and DiagnosticReport.

Predictive Maintenance: evaluates trends and estimates maintenance needs or remaining useful life. Typical concepts include HealthModel and MaintenanceForecast.

Knowledge and Advisory: retrieves technical information and produces evidence-grounded explanations. Typical concepts include KnowledgeSource and Advisory.

Fleet Management: supports multi-vehicle aggregation, scheduling and reporting. Typical concepts include Fleet and ServicePlan.

Telemetry publishes normalized information to downstream consumers. Diagnostics produces structured reports. Knowledge and Advisory consumes those reports through a defined interface or anti-corruption layer, preventing LLM-specific concepts from contaminating the diagnostic domain model.

6.3 Example Gherkin specification

The following is an illustrative starting point. It is not a claim that the scenarios have already been implemented or passed.

@REQ-DIAG-012 @context:diagnostics @level:system Feature: Read and interpret stored diagnostic trouble codes Scenario: Report a diagnostic code returned by the vehicle Given the diagnostic interface is connected And the vehicle is in the required diagnostic state And the vehicle returns a recognized diagnostic code When the technician requests a diagnostic read Then the report includes the returned code And the report identifies the applicable code definition source @degraded Scenario: Vehicle does not respond to a diagnostic request Given the diagnostic interface is connected And the vehicle does not respond within the configured timeout When the technician requests a diagnostic read Then the report states that no valid response was received And the system does not fabricate a diagnostic code @REQ-KNOW-006 @context:knowledge Scenario: Advisory requires supporting service information Given a diagnostic report has been produced And no applicable supporting service-manual passage is available When the technician requests repair guidance Then the system states that sufficient supporting evidence is unavailable And the system does not present an unsupported repair procedure

The test suite should obtain authoritative code definitions from applicable SAE/ISO references and manufacturer documentation. The example does not establish the correct meaning of any particular DTC for every vehicle.

6.4 Testing the RAG and LLM components

LLM output is probabilistic. Exact sentence equality is therefore often an unsuitable acceptance criterion.

Tests should evaluate measurable properties such as:

  • Whether cited passages actually exist in the retrieved evidence.
  • Whether sources apply to the specified vehicle and diagnostic condition.
  • Whether unsupported claims are absent.
  • Whether the system acknowledges missing evidence.
  • Whether units and numerical ranges are valid where relevant.
  • Whether unsafe or contradictory recommendations are detected.
  • Whether the same curated evaluation cases produce acceptable results across releases.

A controlled evaluation dataset should contain representative diagnostic cases, expected supporting passages, known failure cases and expert-reviewed acceptance criteria.

Passing a retrieval or citation check alone does not prove that a recommendation is technically correct. Domain review remains necessary.

6.5 Hardware/software co-design

The embedded Puck may need to acquire bus messages, buffer data, decode diagnostic responses and meet timing constraints. These requirements affect processor selection, memory, communication bandwidth and potential hardware acceleration.

A SystemC TLM-2.0 virtual platform can represent major system modules, including:

  • OBDMaster for protocol sequencing.
  • SimpleBus for interconnect behaviour.
  • AIAccelerator for optional inference or filtering offload.
  • DTCMemory for diagnostic-code storage and lookup.

The model can support early exploration of latency, memory organization and bus architecture before the final hardware is available. Its usefulness depends on the fidelity of its assumptions and timing annotations.

A common behavioural specification can be exercised at multiple levels:

Verification level

Target

Primary objective

Component

Software reference decoder

Fast functional regression

System

SystemC TLM-2.0

Architecture and timing exploration

Integration

Embedded Puck with vehicle-bus simulator

Protocol and interface validation

Hardware

FPGA or target hardware where appropriate

Timing and implementation behaviour

Shared scenarios coordinate the tests, but the adapter and assertion layers must account for differences in timing, observability and abstraction. Agreement between a software reference and a virtual platform does not establish that the physical product is safe or compliant.

7. Case Study B: Smart Inverter for Distributed Energy Resources

7.1 System overview

The second case is a proposed 1 kW single-phase grid-connected smart inverter. Its architecture includes a DC energy source, power-conversion stage, digital controller, grid interface, communications and protection functions.

The design uses MATLAB/Simulink for control and system simulation and Sparx Enterprise Architect for the MBSE architecture.

The relevant standards and profiles include IEEE 1547-2018, UL 1741 and applicable supplements, IEEE 2030.5 and SunSpec Modbus. The project must verify the current applicable editions, amendments, jurisdictional requirements and utility interconnection rules before implementation or compliance claims.

7.2 Bounded contexts

Six proposed contexts establish explicit responsibilities:

Power Conversion: switching stage, DC link, filter and current/voltage regulation.

Grid Interface: synchronization, grid measurements, anti-islanding behaviour, ride-through and grid-disconnection logic.

Grid Support: volt-var, volt-watt, frequency-watt and other configured support functions.

Energy Source: photovoltaic or battery input, maximum power point tracking or applicable charge-control functions.

Supervision and Communications: telemetry, setpoints, firmware management, external interfaces and cybersecurity controls.

Protection and Safety: overcurrent, voltage and frequency limits, thermal protection and fault handling.

The separation between grid policy and the underlying power-control implementation allows applicable grid-support requirements to change without unnecessarily restructuring the entire control architecture. Interfaces and interactions still require verification.

7.3 Example volt-var scenario

The following scenario illustrates specification structure. It intentionally avoids prescribing universal grid settings.

@REQ-INV-021 @context:grid-support @level:model Feature: Volt-var response to grid voltage deviation Scenario Outline: Reactive power follows the configured curve Given the inverter is synchronized And the volt-var function is enabled And the approved grid-support profile is loaded And the grid voltage is <voltage_pu> per unit When the controller reaches the defined evaluation condition Then the reactive power response is within the approved tolerance And the apparent power remains within the applicable rating Examples: | voltage_pu | | 0.95 | | 1.00 | | 1.05 |

These voltage values are illustrative test points, not universal trip thresholds or a prescribed compliant volt-var curve. The approved profile must define the actual curve, tolerances, operating conditions and measurement method.

A protection-related scenario could additionally require the inverter to stop energizing the grid after a configured abnormal condition meets the applicable trip criteria, with the event recorded for review.

7.4 Multi-level verification

The inverter verification strategy should cover:

Model level: MATLAB/Simulink closed-loop simulations of the grid, filter and controller.

SIL: controller software executing on a host against defined inputs and expected outputs.

PIL: target-processor execution where appropriate, with attention to numerical behaviour and execution timing.

HIL: real controller hardware interacting with a real-time simulator to assess integration, I/O effects and protection response.

The same requirement identifiers and behavioural intent can connect these stages, while each stage uses suitable numerical, timing and physical assertions.

Gherkin is not a replacement for waveform analysis, stability analysis, switching simulations, thermal calculations or formal protection verification. It can coordinate the test workflow and provide traceability to the detailed verification artefacts.

7.5 Cybersecurity and safety governance

The architecture should treat cybersecurity as a first-class concern. Relevant behaviours include:

  • Rejection of unauthenticated or unauthorized setpoint changes.
  • Validation of message formats and parameter ranges.
  • Controlled firmware updates and verification of firmware authenticity.
  • Appropriate logging of configuration changes.
  • Defined responses to communication loss and invalid commands.
  • Protection against unauthorized weakening of safety-related behaviour.

Specific security mechanisms and assurance levels must be chosen according to the product threat model and applicable requirements. An AI assistant should not be permitted to weaken protection tests or modify approved safety evidence without formal authorization.

8. DevOps and Continuous Verification

8.1 Continuous integration workflow

A practical pipeline should execute a staged set of checks:

  1. Validate identifiers, file formats and repository conventions.
  2. Lint Gherkin features and verify step-definition coverage.
  3. Run fast unit tests and static analysis.
  4. Run domain and integration tests.
  5. Validate EA export consistency and traceability.
  6. Build and execute relevant SystemC or Simulink tests.
  7. Run approved SIL/PIL/HIL tests when the required equipment and configuration are available.
  8. Generate a verification report with source revisions and test configuration.
  9. Require human approval for release-critical and safety-related changes.

Not every pipeline execution must run every hardware test. Long-running simulations and laboratory tests may be scheduled in dedicated stages, but their results must remain linked to the relevant baseline.

8.2 Reproducible evidence

A useful test record should identify:

  • Requirement and scenario identifiers.
  • Source-code and model revision.
  • Tool and compiler versions.
  • Test configuration and input dataset.
  • Hardware and firmware configuration where applicable.
  • Execution date and outcome.
  • Logs, simulation results and relevant measurements.
  • Reviewer and disposition of failures.

This makes the verification history more useful for engineering review, defect investigation and later change-impact analysis.

8.3 Engineering quality gates

A release should not be considered ready merely because generated code compiles.

Minimum gates should include:

  • No unexplained traceability gaps for in-scope requirements.
  • No unreviewed changes to protected architecture or safety artefacts.
  • Meaningful test assertions with reviewed coverage.
  • Resolution or documented disposition of relevant test failures.
  • Approval of architecture decisions affecting interfaces or system boundaries.
  • Review of verification evidence by accountable engineers.

The exact thresholds should be defined by project risk and customer requirements rather than copied indiscriminately from another product.

9. Governance, Risk and Quality Assurance

AI-assisted architecture introduces risks beyond ordinary software development. The following controls are proposed.

Risk

Control

Invented standards requirements or diagnostic meanings

Controlled authoritative sources, citations to applicable clauses or manual passages, and expert review

Requirements and models drift apart

Stable identifiers, export baselines, automated traceability checks and change review

Tests are weakened to make a build pass

Protected test files, safety tags, change detection and mandatory approval

Generated tests assert too little

Assertion-strength reviews, fault injection and mutation testing

Confidential engineering information is exposed

Data classification, permission scoping, approved assistant configuration and secrets management

Incorrect terminology crosses domain boundaries

Context-specific glossaries and automated consistency checks

External documents manipulate assistant behaviour

Treat retrieved content as untrusted data; restrict permissions and validate outputs

Simulation results are mistaken for hardware proof

Explicit fidelity assumptions and separate SIL, PIL, HIL and physical verification

Certification claims exceed the available evidence

Formal review and sign-off by the responsible engineering organization

The guiding principle is to use automation for repeatable checks and human judgment for consequential decisions.

The assistant should propose changes, explain its assumptions and identify uncertainty. It should not independently approve architecture baselines, certify products or make safety-critical engineering decisions.

10. Evaluation Methodology and Key Performance Indicators

The methodology must be evaluated through an instrumented pilot. No productivity or quality improvement is claimed as an established result in this paper.

10.1 Study design

A practical pilot could compare matched work packages developed using the proposed workflow with similar packages developed using the organization's existing method.

The comparison should document differences in complexity, team experience, tool maturity and project constraints. Where possible, the team should use the same acceptance criteria and record the assistant version, configuration and prompts.

10.2 Proposed KPIs

KPI

Measurement approach

Interpretation

Specification effort

Engineer-hours from approved brief to reviewed executable feature

Lower effort may indicate improved drafting efficiency, provided quality is maintained

Requirement ambiguity

Number and severity of ambiguities found during structured review

Indicates clarity of requirements

Traceability completeness

In-scope requirements with complete required links divided by total in-scope requirements

Measures traceability, not correctness

Change-impact turnaround

Time required to identify affected models, tests and components

Measures usefulness of architecture links

Escaped defects

Relevant defects first discovered at later verification stages

Indicates effectiveness of earlier checks

Mutation score

Proportion of selected injected faults detected by tests

Helps evaluate whether tests detect incorrect behaviour

Early architectural defect detection

Relevant defects identified in simulation or model stages before hardware integration

Indicates the value of early verification

AI review overhead

Human review time spent on generated artefacts

Measures governance cost

False-positive rate

Proportion of automated findings determined to be non-actionable

Indicates the precision of automated checks

Evidence reproducibility

Proportion of sampled results reproducible from recorded configuration and revisions

Measures verification-record quality

Metrics should be reported with sample size, project context and limitations. Small pilots can provide useful operational evidence but should not be presented as statistically conclusive without an appropriate study design.

10.3 Acceptance criteria for the pilot

Before implementation, the project team should define:

  • Which bounded context is in scope.
  • Which requirements and scenarios must be traceable.
  • Which tests must run automatically.
  • Which model exchanges require manual review.
  • What evidence is required for acceptance.
  • Which baseline is used for comparison.
  • What findings would justify expanding, changing or stopping the pilot.

Predefining these criteria reduces the risk of declaring success solely because the workflow produces more artefacts.

11. Strategic Business Model: IAS-Research.com and KeenComputer.com

The technical method creates an opportunity to combine independent research and architecture advisory with practical implementation and managed engineering services.

11.1 IAS-Research.com: research, architecture and technical assurance

IAS Research can position itself as an engineering research and innovation partner for organizations developing software-intensive and cyber-physical products.

Potential services include:

  • Enterprise Architecture and MBSE assessments.
  • UML/SysML architecture and requirements modelling.
  • DDD bounded-context design and context mapping.
  • BDD acceptance criteria and executable specification strategy.
  • AI-assisted engineering governance.
  • Hardware/software co-design and simulation strategy.
  • SystemC TLM-2.0 architecture exploration.
  • Smart inverter and DER control-system architecture.
  • RAG/LLM architecture and evidence-grounding evaluation.
  • Technical white papers, architecture reviews and research prototypes.

IAS Research should own the conceptual framework, research methodology, architecture decisions and technical assurance scope agreed with each client.

11.2 KeenComputer.com: implementation and operational delivery

KeenComputer can translate the approved architecture into working engineering workflows and deployed services.

Potential delivery services include:

  • Repository and CI/CD pipeline setup.
  • Gherkin and Cucumber implementation.
  • Traceability-checking scripts and model-export automation.
  • Claude Code configuration and engineering guardrails.
  • SystemC build and simulation environments.
  • Test automation and integration adapters.
  • Secure development environments and DevOps support.
  • Documentation generation, release reporting and maintenance.
  • Integration with customer issue tracking and engineering workflows.

KeenComputer's value proposition should focus on the client's business outcomes: reducing rework, improving visibility, accelerating controlled delivery and making technical handovers more reliable.

11.3 Joint delivery model

Phase

IAS-Research.com

KeenComputer.com

Client outcome

Discover

Assess requirements, domain and architecture risks

Review existing repositories and toolchain

Agreed problem statement and baseline

Design

Define architecture, bounded contexts and verification strategy

Design implementation and automation workflow

Approved technical plan

Prototype

Validate engineering hypotheses and model fidelity

Build repository, adapters and initial pipeline

Working pilot

Verify

Review technical assumptions and evidence

Execute automated checks and report results

Traceable test evidence

Deploy

Review architecture and assurance boundaries

Integrate and operationalize the workflow

Repeatable engineering process

Improve

Research gaps and architecture evolution

Maintain tools, scripts and CI/CD

Continuous improvement

The organizations should clearly distinguish advisory conclusions from implementation commitments and avoid implying that a generic workflow automatically confers regulatory compliance.

11.4 Target customers

The initial target market includes:

  • Small and medium-sized embedded-software firms.
  • Automotive diagnostic tool developers.
  • Industrial automation companies.
  • Power electronics and DER developers.
  • Engineering consultancies working on mixed hardware/software systems.
  • Organizations adopting AI-assisted software engineering.
  • Teams that use UML/SysML but lack automated traceability and verification integration.

A focused first offer could be an Executable Architecture Pilot for one bounded context, including a model and requirements baseline, an approved Gherkin feature set, automated traceability checks and a demonstration test pipeline.

This is more practical than attempting to transform an entire engineering organization in a single engagement.

12. Implementation Roadmap

Phase 1: Foundation

  • Select one bounded context from OBD-AI and one from the inverter project.
  • Establish repository conventions and stable identifiers.
  • Export the existing Sparx EA requirements and relevant model elements.
  • Create context maps and domain glossaries.
  • Define the initial quality and security gates.

Deliverable: a version-controlled architecture baseline.

Phase 2: Executable specifications

  • Write a small set of high-value Gherkin scenarios.
  • Review each scenario with domain, development and verification stakeholders.
  • Implement step definitions and meaningful assertions.
  • Connect the scenarios to requirement identifiers.
  • Add the first traceability checker.

Deliverable: approved behavioural specifications with executable tests.

Phase 3: Simulation integration

  • Build the OBD-AI software reference tests and SystemC adapter.
  • Build the initial MATLAB/Simulink bridge for the inverter.
  • Establish repeatable simulation configurations.
  • Compare outputs and investigate differences between representations.

Deliverable: traceable model-level verification.

Phase 4: AI-assisted workflow

  • Add project instructions and reusable engineering commands.
  • Restrict writes to protected paths.
  • Automate linting, traceability and test execution.
  • Require review of model deltas and safety-related changes.
  • Record AI configuration and generated changes for reproducibility.

Deliverable: a governed AI-assisted engineering workflow.

Phase 5: Hardware integration and evaluation

  • Add Puck or FPGA testing using a suitable vehicle-bus simulator.
  • Add MCU/FPGA and HIL tests for the inverter where equipment is available.
  • Capture evidence and review defects discovered at each level.
  • Measure the defined KPIs against the baseline.
  • Decide whether to expand the workflow based on observed results.

Deliverable: a pilot evaluation report and an evidence-based scale-up decision.

13. Discussion

13.1 Principal strengths

The proposed framework connects requirements, domain language, architecture models and tests through explicit identifiers. It also provides a controlled place for AI-assisted drafting and consistency checks.

Its multi-target strategy is particularly relevant to cyber-physical systems because the same behavioural intent can inform several forms of verification without assuming that all targets have identical capabilities.

For SMEs, a bounded-context pilot can establish practical value before the organization invests in broad process changes or extensive tool integration.

13.2 Limitations

Gherkin is not designed to express every property of a complex engineering system. Detailed waveform behaviour, control stability, electromagnetic effects, processor timing and safety properties require appropriate specialist techniques.

EA export/import workflows introduce maintenance effort, and text-based diffs may not fully explain semantic model changes. Model synchronization must therefore remain a governed activity.

AI-generated code and tests may be plausible but incorrect. LLM-based advisory systems remain probabilistic, and traceability cannot by itself establish the validity of a model, test or conclusion.

Finally, the methodology's effectiveness depends on disciplined requirements engineering, appropriate tool integration, domain expertise and meaningful verification—not merely on adopting an AI assistant.

13.3 Research opportunities

Further work could investigate:

  • Automated semantic comparison of EA model baselines.
  • Generation and validation of traceability links from stable identifiers.
  • Common behavioural specifications across virtual platforms and physical targets.
  • Evaluation of AI-generated test quality using mutation testing.
  • Reproducible benchmarks for AI-assisted architecture maintenance.
  • Integration of RAG-based engineering assistants with controlled standards and technical-document repositories.
  • Methods for connecting architecture decisions to measurable system quality attributes.

These are proposed research directions and require separate implementation and evaluation.

14. Conclusions and Recommendations

This paper proposes an engineering method in which architecture is connected to executable behavioural specifications, verification and controlled evidence.

The principal recommendations are:

  1. Keep requirements, domain glossaries, architecture decisions, features and test code under version control.
  2. Retain Sparx Enterprise Architect as the governed modelling environment, with deliberate export/import and review procedures.
  3. Use DDD to define responsibilities and maintain consistent domain terminology.
  4. Use BDD and Gherkin to express observable behaviours that matter to stakeholders.
  5. Use Cucumber or compatible test tooling to execute meaningful assertions.
  6. Apply software, SystemC, Simulink, SIL, PIL and HIL verification at the levels appropriate to each requirement.
  7. Use AI assistants for bounded drafting and consistency tasks, not independent safety or certification decisions.
  8. Enforce mechanical rules through automated checks and CI/CD rather than relying on prompts alone.
  9. Measure effort, defect detection, traceability and review overhead before claiming productivity benefits.
  10. Begin with a small, high-value pilot and expand only after the evidence supports doing so.

For IAS-Research.com and KeenComputer.com, this approach offers a coherent bridge between engineering research and practical delivery: architecture and innovation strategy on one side, implementation and operational engineering on the other.

The intended result is not simply more documentation or more generated code. It is a better-governed relationship between what a system is required to do, how it is designed, how that design is implemented and how its behaviour is verified.

References

  1. Evans, E. (2003). Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley.
  2. Vernon, V. (2013). Implementing Domain-Driven Design. Addison-Wesley.
  3. Smart, J. F. (2014). BDD in Action: Behavior-Driven Development for the Whole Software Lifecycle. Manning Publications.
  4. North, D. (2006). “Introducing BDD.” Better Software.
  5. Wynne, M., and Hellesøy, A. (2012). The Cucumber Book: Behaviour-Driven Development for Testers and Developers. Pragmatic Bookshelf.
  6. IEEE. IEEE Std 1666: SystemC Language Reference Manual. Verify the applicable edition for the project.
  7. IEEE. IEEE Std 1547-2018: Standard for Interconnection and Interoperability of Distributed Energy Resources with Associated Electric Power Systems Interfaces. Verify applicable amendments and current requirements.
  8. UL Standards & Engagement. UL 1741: Inverters, Converters, Controllers and Interconnection System Equipment for Use With Distributed Energy Resources, including applicable supplements. Verify the current edition and certification scope.
  9. IEEE. IEEE Std 2030.5: Smart Energy Profile Application Protocol. Verify the applicable edition.
  10. SAE International. SAE J1979 and SAE J2012. Verify the applicable editions and relevant vehicle diagnostic requirements.
  11. International Organization for Standardization. ISO 15031 series, concerning road vehicles and emissions-related diagnostic communication. Verify the relevant parts and editions.
  12. Anthropic. Claude Code Documentation. Consult the current official documentation for project instructions, permissions, hooks, agents and supported integrations.
  13. Sparx Systems. Enterprise Architect User Guide. Consult the documentation applicable to Enterprise Architect 15.2 and the project's selected modelling technologies.
  14. The Open Group. TOGAF Standard. Consult the applicable edition.
  15. Object Management Group. Unified Modeling Language (UML) Specification. Consult the applicable edition.
  16. Object Management Group. Systems Modeling Language (SysML) Specification. Consult the applicable edition.

Reference note: Standards editions, amendments, publication details and applicable regulatory requirements must be verified before formal submission, implementation or compliance claims.

Suggested publication metadata

Proposed page title: Executable Enterprise Architecture with UML, DDD, BDD and AI-Assisted Engineering

Meta description: Explore an executable architecture framework integrating Sparx EA 15.2, UML/SysML, DDD, Gherkin, Cucumber, Claude Code, SystemC and Simulink for OBD-AI and smart inverter DER engineering.

Suggested URL slug: executable-enterprise-architecture-bdd-ddd-ai-engineering

Suggested keywords: Enterprise Architecture, Sparx Enterprise Architect 15.2, UML, SysML, MBSE, DDD, BDD, Gherkin, Cucumber, Claude Code, SystemC TLM-2.0, hardware software co-design, OBD-AI, RAG LLM, smart inverter, DER, SIL, HIL, IAS Research, KeenComputer.

Suggested call to action: Contact IAS-Research.com for an architecture and engineering assessment, and KeenComputer.com for implementation of an executable-specification and continuous-verification pilot.

The paper is grounded in the uploaded 18-page source, including its five OBD-AI bounded contexts, six smart-inverter contexts, proposed Claude Code governance, Sparx EA synchronization approach and evaluation plan.

Using Claude Code for Enterprise Architecture BDD, DDD, Gherkin and Cucumber Applied to OBD-AI and Smart Inverter DER Pr.pdf