Object Management Group -Integrated MBSE-Driven Electronic System Design for Industrial IoT and Predictive Maintenance

An End-to-End SysML, Sparx Enterprise Architect, SystemC/TLM, Virtual Platform, RTOS, Embedded Linux, VLSI/FPGA, AI, Microservices, API, BDD and DevSecOps Methodology

Prepared for: IAS-Research, KeenComputer, and KeenDirect
Author: IASR-KEEN-KEENDIRECT
Discipline: Systems Engineering, MBSE, Hardware–Software Co-Design, VLSI, Embedded Systems, Industrial IoT, AI/ML and Software Engineering
Version: 2.0
Date: October 2026

Abstract

Industrial Internet of Things (IIoT) predictive maintenance is increasingly becoming a multidisciplinary engineering problem involving mechanical assets, sensors, analog electronics, embedded processors, real-time operating systems, FPGA/VLSI accelerators, embedded Linux, industrial networking, artificial intelligence, cybersecurity, cloud/edge computing, software engineering, and maintenance operations.

A major weakness of many industrial predictive-maintenance programs is that these domains are developed independently. Data scientists may optimize machine-learning models without understanding sensor limitations; hardware engineers may optimize acquisition hardware without understanding software workloads; embedded engineers may discover memory and timing limitations late in development; software teams may develop APIs without understanding OT constraints; and maintenance organizations may receive alerts without an actionable workflow.

This paper proposes an Integrated Model-Based Systems Engineering (MBSE) methodology that treats predictive maintenance as a complete cyber-physical product-development problem.

The methodology integrates:

  • SysML/SysML v2 for system requirements, architecture, behavior, interfaces and traceability.
  • Sparx Enterprise Architect for MBSE repository management and systems/software architecture.
  • UML for software architecture and implementation models.
  • SystemC/TLM for executable architectural modeling and hardware/software co-design.
  • Virtual platforms and QEMU for pre-hardware software development.
  • RTOS for deterministic embedded execution.
  • Embedded Linux and Yocto for sophisticated edge computing.
  • FPGA/VLSI for deterministic acceleration and high-rate signal processing.
  • Docker and microservices for portable edge services.
  • REST/OpenAPI for service integration.
  • Postman for API and integration testing.
  • BDD, Cucumber and Gherkin for executable behavioral requirements.
  • CI/CD and DevSecOps for automated engineering workflows.
  • AI/ML for anomaly detection, fault diagnosis and prognostics.
  • IEC 62443 for industrial cybersecurity.
  • Hardware-in-the-loop (HIL) and field validation for final system assurance.

The central proposition is:

MBSE defines what the system must accomplish; SystemC/TLM and virtual platforms explore how it will behave; RTOS, embedded Linux and FPGA/VLSI implement the platform; Docker and microservices provide scalable edge services; REST/OpenAPI define software contracts; Postman validates interfaces; BDD/Cucumber/Gherkin makes requirements executable; and HIL and field testing establish evidence that the complete cyber-physical system works in its operational environment.

This creates an integrated engineering chain from stakeholder requirement to architecture, virtual prototype, implementation, automated verification, physical prototype, predictive-maintenance decision, and industrial operation.

1. Executive Summary

1.1 Industrial context

Industrial equipment failure can create:

  • production downtime
  • emergency maintenance
  • lost production capacity
  • safety exposure
  • quality problems
  • energy inefficiency
  • spare-parts costs
  • expedited logistics
  • reduced asset life.

Predictive maintenance attempts to identify degradation early enough to allow planned intervention.

Recent academic literature confirms the increasing importance of predictive maintenance within Industry 4.0, while also identifying challenges involving data, algorithms, industrial deployment, integration and multidisciplinary engineering. DOI

The problem, however, is larger than AI.

A successful predictive-maintenance product may contain:

Industrial Asset | Sensors | Analog Front End | ADC / DAQ | MCU / DSP / FPGA | RTOS | Embedded Linux | Docker Microservices | MQTT / OPC UA / REST | AI / Analytics | Maintenance Decision | CMMS / ERP | Technician

Every interface represents a potential engineering failure.

2. Research Proposition

The paper proposes that industrial predictive maintenance should be developed using a digital engineering continuum:

Business Need ↓ Stakeholder Need ↓ SysML Requirements ↓ System Architecture ↓ SystemC/TLM ↓ Virtual Platform ↓ QEMU / Embedded Linux / RTOS ↓ FPGA/VLSI ↓ Docker Microservices ↓ REST/API Integration ↓ BDD / Cucumber / Gherkin ↓ CI/CD / DevSecOps ↓ HIL ↓ Industrial Pilot ↓ Maintenance Outcome

This is the principal research and industrial contribution of the proposed methodology.

3. Research Objectives

The project has ten primary objectives.

Objective 1 — MBSE

Develop a traceable SysML-based model of the predictive-maintenance system.

Objective 2 — Architecture

Create an architecture that connects physical assets, sensing, embedded electronics, communications, analytics and maintenance operations.

Objective 3 — Virtual engineering

Develop SystemC/TLM and virtual-platform models before physical hardware is finalized.

Objective 4 — Embedded computing

Integrate RTOS, embedded Linux, QEMU and hardware abstraction into the methodology.

Objective 5 — Hardware acceleration

Evaluate FPGA and VLSI implementations for signal processing and edge AI.

Objective 6 — Software architecture

Develop containerized microservices and API-driven integration.

Objective 7 — Executable requirements

Use BDD/Gherkin/Cucumber to convert operational requirements into automated tests.

Objective 8 — Security

Integrate cybersecurity into the engineering lifecycle using IEC 62443 principles.

Objective 9 — Predictive analytics

Integrate sensor processing, feature engineering, machine learning and maintenance workflows.

Objective 10 — Commercialization

Create reusable intellectual property, reference architectures, engineering services and industrial training through IAS-Research, KeenComputer and KeenDirect.

4. Research Questions

The following research questions guide the proposed methodology.

  1. How can SysML requirements be connected to executable SystemC/TLM models?
  2. How can virtual platforms reduce hardware/software integration risk?
  3. How can QEMU accelerate embedded Linux development before hardware availability?
  4. How should RTOS and Embedded Linux coexist in an industrial edge device?
  5. Which functions should be implemented in software, FPGA or ASIC?
  6. How can Docker microservices be safely deployed at the industrial edge?
  7. How can REST/OpenAPI interfaces be traced back to system requirements?
  8. Can BDD/Gherkin provide executable traceability between requirements and integration tests?
  9. How can predictive-maintenance AI be integrated into a safety-conscious cyber-physical architecture?
  10. How can IEC 62443 cybersecurity requirements become part of the MBSE model?
  11. How can this methodology reduce late hardware/software integration failures?
  12. How can the resulting engineering framework become a reusable commercial platform?

5. Literature and Standards Foundation

The methodology combines several established engineering traditions rather than attempting to replace them.

5.1 Model-Based Systems Engineering

MBSE uses an evolving system model as a central engineering artifact. Academic work identifies MBSE as a means of managing increasing system complexity, maintaining consistency and improving traceability across specification, design, validation and configuration management. INCOSE Online Library

SysML is particularly relevant because it provides constructs for requirements, structure, behavior, analysis and verification.

OMG's current SysML v2.0 specification provides a more precise and semantically rigorous foundation and includes textual notation and an API intended to improve interoperability across the digital-engineering ecosystem. Object Management Group

5.2 Architecture Description

ISO/IEC/IEEE 42010:2022 defines requirements for architecture descriptions and distinguishes architecture from the description used to communicate and manage it. It also addresses architecture viewpoints, frameworks, architecture-description languages and model kinds. ISO

The proposed methodology therefore treats architecture as a set of coordinated viewpoints:

  • operational
  • functional
  • logical
  • physical
  • software
  • hardware
  • communication
  • cybersecurity
  • maintenance
  • deployment.

5.3 SystemC

IEEE 1666-2023 defines SystemC as a C++ class library for system and hardware design, particularly for systems combining hardware and software. IEEE Standards Association

SystemC therefore provides a suitable foundation for:

  • architectural exploration
  • virtual prototyping
  • transaction-level modeling
  • hardware/software partitioning
  • performance analysis
  • accelerator modeling.

The SystemC literature also emphasizes TLM as a method for modeling complex hardware/software systems at higher abstraction levels. Springer Link

6. Sparx Enterprise Architect as the MBSE Repository

Sparx Enterprise Architect provides a practical environment for connecting requirements, architecture, software, systems engineering and traceability. Its documentation describes SysML-based requirements and system modeling capabilities, while its broader platform supports requirements tracing through analysis, design, implementation, testing and maintenance. Sparx Systems

The proposed repository structure is:

00_Governance 01_Stakeholders 02_Missions 03_Use_Cases 04_Requirements 05_System_Architecture 06_Behavior 07_Interfaces 08_Parametrics 09_Hardware 10_FPGA_VLSI 11_RTOS 12_Embedded_Linux 13_SystemC_TLM 14_Virtual_Platform 15_QEMU 16_Software 17_Microservices 18_APIs 19_AI_ML 20_Cybersecurity 21_BDD 22_Testing 23_HIL 24_Deployment 25_Maintenance 26_Risk 27_Decisions 28_Traceability 29_Configuration

7. System Requirements Engineering

Requirements should be categorized into:

Category

Examples

Functional

Detect bearing degradation

Performance

Alert within 5 seconds

Timing

Sensor sampling every 1 ms

Hardware

ADC resolution

Software

RTOS response time

Environmental

Temperature/vibration

Interface

MQTT/REST/OPC UA

Security

Device authentication

Safety

Fail-safe behavior

Maintainability

OTA update

AI

Detection accuracy

Operational

Work-order generation

Regulatory

Applicable standards

Example:

REQ-PM-014 The system shall detect a validated bearing-degradation condition within five seconds of acquisition of the final relevant sensor sample. Verification: SystemC/TLM simulation Software integration test Hardware-in-the-loop test Field validation

8. Requirements Traceability

The central traceability chain is:

Stakeholder Need ↓ System Requirement ↓ Functional Requirement ↓ Architecture Element ↓ Hardware/Software Allocation ↓ Implementation ↓ Test Case ↓ Test Evidence ↓ Operational KPI

A requirement should not be considered closed merely because a document says it is implemented.

It should be closed when evidence exists.

9. Reference Cyber-Physical Architecture

The proposed architecture consists of eight major layers.

+--------------------------------------+ | Business / Maintenance | | CMMS / ERP / MES / Dashboard | +--------------------------------------+ | Analytics / AI / Digital Twin | +--------------------------------------+ | Industrial Integration | | OPC UA / MQTT / REST | +--------------------------------------+ | Edge Microservices | | Docker / Containers | +--------------------------------------+ | Embedded Linux | +--------------------------------------+ | RTOS / MCU / FPGA | +--------------------------------------+ | Sensor / Analog / ADC | +--------------------------------------+ | Physical Industrial Asset | +--------------------------------------+

10. Physical Asset Layer

Typical assets include:

  • motors
  • pumps
  • compressors
  • fans
  • conveyors
  • gearboxes
  • transformers
  • HVAC systems
  • CNC equipment
  • industrial robots.

Failure modes may include:

  • bearing wear
  • imbalance
  • shaft misalignment
  • looseness
  • overheating
  • lubrication failure
  • cavitation
  • electrical degradation
  • insulation failure
  • mechanical fatigue.

Failure-mode analysis should be performed before selecting sensors.

11. Sensor and Signal-Conditioning Architecture

Potential measurements include:

Mechanical

  • vibration
  • acoustic emissions
  • displacement
  • speed.

Electrical

  • voltage
  • current
  • power
  • harmonics.

Thermal

  • temperature
  • thermal gradients.

Process

  • pressure
  • flow
  • humidity
  • fluid quality.

The engineering chain is:

Physical Phenomenon ↓ Sensor ↓ Analog Front End ↓ Filtering ↓ Isolation / Protection ↓ ADC ↓ DMA ↓ Memory

Sensor selection must consider:

  • bandwidth
  • sensitivity
  • noise
  • calibration
  • temperature coefficient
  • dynamic range
  • sampling rate
  • installation
  • EMC.

12. RTOS Architecture

RTOS is appropriate for deterministic functions.

A typical implementation is:

RTOS | +-- Sensor Acquisition +-- DMA +-- DSP +-- Feature Extraction +-- Alarm Logic +-- Communications +-- Watchdog +-- Diagnostics +-- Secure Update

Example timing requirements:

Sensor acquisition < 1 ms DMA completion < 200 µs Feature extraction < 500 µs Local alarm decision < 100 ms Health-status update < 1 s

The exact limits must be derived from the application rather than assumed.

13. Embedded Linux

Embedded Linux becomes valuable when the edge device requires:

  • advanced networking
  • containerized services
  • AI frameworks
  • databases
  • secure remote administration
  • complex middleware
  • graphical interfaces
  • OTA management.

The Yocto Project provides tools and methods for creating customized Linux-based systems for connected edge devices, servers and virtual environments across hardware architectures. Yocto Project

A typical platform is:

Application ↓ Microservices ↓ Container Runtime ↓ Embedded Linux ↓ Bootloader ↓ SoC

14. RTOS + Embedded Linux Coexistence

A heterogeneous SoC can divide responsibilities:

SoC | +--------+--------+ | | RTOS Linux | | Deterministic Complex Apps Functions | | Docker | Microservices | | +------IPC--------+

RTOS handles:

  • timing-critical acquisition
  • protection
  • deterministic processing
  • watchdog.

Linux handles:

  • networking
  • databases
  • AI
  • REST
  • dashboards
  • containers
  • device management.

This architecture should be evaluated using SysML allocation models and SystemC/TLM simulations.

15. QEMU

QEMU provides full-system emulation in which a virtual machine model can include CPU, memory and emulated devices, allowing guest operating systems to execute before the target hardware is available. QEMU

QEMU can support:

  • Embedded Linux development
  • kernel development
  • device-driver development
  • network testing
  • automated regression
  • boot testing
  • failure reproduction.

The development sequence becomes:

SysML ↓ Architecture ↓ QEMU Model ↓ Linux ↓ Drivers ↓ Applications ↓ Physical Hardware

QEMU does not replace SystemC/TLM; they serve different abstraction purposes.

16. SystemC/TLM

SystemC/TLM should be used for architectural questions such as:

  • processor utilization
  • bus bandwidth
  • DMA contention
  • interrupt latency
  • memory bottlenecks
  • accelerator throughput
  • sensor-to-alert latency.

A representative model:

Sensor Model | ADC | DMA | Memory | CPU | DSP / FPGA Accelerator | AI Inference | Network

The model can be exercised with:

  • nominal workloads
  • peak workloads
  • network delays
  • sensor faults
  • dropped packets
  • processor contention
  • memory pressure.

17. Virtual Platforms

A virtual platform should provide an executable representation of the embedded target.

Components can include:

CPU Memory Interrupt Controller DMA Timers SPI I2C UART Ethernet ADC Sensors Storage FPGA Accelerator Network

Software can be developed against the virtual platform before physical hardware exists.

This can reduce dependency on prototype boards during early development.

18. SystemC/TLM vs QEMU vs FPGA vs HIL

Technology

Primary objective

SysML

Requirements and architecture

SystemC/TLM

Architectural simulation

Virtual Platform

Pre-silicon software execution

QEMU

Processor/system emulation

RTL

Hardware correctness

FPGA

Hardware prototype

HIL

Integrated system verification

Field Pilot

Operational validation

They should be viewed as a verification ladder, not competing technologies.

19. FPGA and VLSI

High-throughput signal-processing workloads may justify FPGA or ASIC implementation.

Candidate functions include:

  • FFT
  • FIR filtering
  • IIR filtering
  • envelope detection
  • spectral analysis
  • wavelet transforms
  • feature extraction
  • neural-network inference
  • cryptographic acceleration.

The decision should consider:

Performance Power Area Cost Volume Latency Security IP Protection Development Time

ASIC development should normally occur only after architecture and workload requirements justify the NRE and verification effort.

20. Hardware–Software Co-Design

Function allocation should be explicitly modeled.

Function

Candidate

Sensor acquisition

MCU/RTOS

High-speed filtering

FPGA

FFT

FPGA/DSP

Lightweight AI

MCU/NPU/FPGA

Complex AI

Linux/edge server

Fleet analytics

Server/cloud

Device management

Linux

Safety interlock

Dedicated safety architecture

Maintenance workflow

Microservice/CMMS

Allocation decisions should be validated through simulation and prototype measurements.

21. Docker and Edge Microservices

Docker provides a practical packaging mechanism for non-real-time edge services.

Possible services include:

Asset Service Telemetry Service AI Service Feature Service Alert Service Device Management Authentication REST API MQTT Adapter OPC UA Adapter Database Dashboard Logging Monitoring

A key engineering rule is:

Containers should complement deterministic embedded processing, not replace hard real-time control functions.

22. Microservice Architecture

The platform can use bounded contexts:

Asset Telemetry Diagnostics Inference Alert Maintenance Device Identity Audit

For example:

API Gateway | +-------------+-------------+ | | | Asset Telemetry Diagnostics | | | +-------------+-------------+ | AI Service | Alert Service | Maintenance Service | CMMS

This permits independent evolution of services.

23. REST API

REST interfaces can connect:

  • edge devices
  • microservices
  • mobile applications
  • dashboards
  • CMMS
  • ERP
  • external analytics.

Example:

GET /api/v1/assets GET /api/v1/assets/{id} GET /api/v1/assets/{id}/health GET /api/v1/assets/{id}/telemetry GET /api/v1/alerts POST /api/v1/alerts/{id}/acknowledge GET /api/v1/workorders POST /api/v1/workorders GET /api/v1/models

API requirements must include:

  • authentication
  • authorization
  • schema validation
  • versioning
  • error handling
  • rate limiting
  • logging
  • observability.

24. OpenAPI Contract-First Engineering

The API should preferably be designed as a contract.

SysML Interface Requirement ↓ OpenAPI Contract ↓ Server Implementation ↓ Client Implementation ↓ Postman Tests ↓ Integration Tests

This makes API behavior part of the system-engineering baseline.

25. Postman

Postman can be incorporated into verification for:

  • API functional testing
  • integration testing
  • end-to-end workflows
  • error handling
  • authentication
  • response-time validation.

Postman supports request-level scripts and response assertions, collections and automated execution, including CI/CD integration. Postman Docs

Example:

POST /api/v1/telemetry Expected: HTTP 201 Valid JSON Valid asset ID Valid timestamp Valid measurement Audit event created

Postman can also test multi-service workflows rather than merely individual API calls. Postman Docs

26. Behavior-Driven Development

BDD provides a bridge between:

  • business requirements
  • system requirements
  • engineering behavior
  • automated testing.

The basic chain is:

Requirement ↓ Behavior ↓ Gherkin ↓ Cucumber ↓ Automated Test ↓ Evidence

27. Cucumber and Gherkin

Gherkin uses structured keywords such as Feature, Scenario, Given, When, Then, And and But to express executable specifications. Cucumber maps these steps to step definitions that execute test behavior. Cucumber

Example:

Feature: Bearing degradation detection Scenario: High-confidence bearing anomaly Given the motor is operating under normal load And the vibration sensor is calibrated When the vibration envelope exceeds the validated threshold And the anomaly model reports high confidence Then a bearing degradation alert shall be generated And the affected asset shall be identified And a maintenance recommendation shall be created

This scenario can become an automated acceptance test.

28. BDD for Embedded Fault Handling

Example:

Feature: Sensor communication failure Scenario: Vibration sensor becomes unavailable Given the edge controller is operational And the vibration sensor is connected When the sensor stops responding Then the RTOS shall detect the communication failure And the event shall be logged And vibration data shall be marked invalid And the system shall continue monitoring other sensors

This is especially valuable for fault-injection and HIL testing.

29. Executable Traceability

The methodology introduces an important research concept:

Requirements should progressively become executable. Stakeholder Need ↓ SysML Requirement ↓ Use Case ↓ Architecture ↓ SystemC Model ↓ Software ↓ API ↓ Gherkin ↓ Automated Test ↓ HIL ↓ Field Evidence

This transforms requirements management from a documentation activity into an executable assurance process.

30. CI/CD

The development pipeline should integrate:

Git Commit ↓ Build ↓ Unit Tests ↓ Static Analysis ↓ SystemC/TLM Regression ↓ API Tests ↓ BDD Tests ↓ Security Scan ↓ Docker Build ↓ Integration ↓ HIL ↓ Release

Artifacts include:

  • firmware
  • Linux image
  • device tree
  • FPGA bitstream
  • Docker images
  • AI models
  • API definitions
  • test results.

31. DevSecOps

Security should be integrated throughout the lifecycle.

Source Code ↓ SAST ↓ Dependency Scan ↓ Container Scan ↓ API Security ↓ Firmware Security ↓ SBOM ↓ Signed Release ↓ Deployment

IEC 62443-4-1 specifically addresses secure product development lifecycle requirements, including security requirements definition, secure design, implementation, verification/validation, defect management, patch management and end-of-life. webstore.iec.ch

32. Industrial Cybersecurity

IEC 62443 provides an important framework for IACS security.

The architecture should address:

  • identification/authentication
  • use control
  • system integrity
  • data confidentiality
  • restricted data flow
  • timely response
  • resource availability.

IEC 62443-4-2 defines technical security requirements for IACS components around these foundational requirements. webstore.iec.ch

IEC 62443-3-3 addresses system security requirements and security levels for control systems. webstore.iec.ch

The 2025 IEC PAS 62443-1-6 is particularly relevant because it provides guidance on applying the 62443 series to IIoT environments. webstore.iec.ch

33. Security Architecture

A representative architecture is:

Enterprise IT | Firewall | IT/OT DMZ | Industrial Gateway | +-----+----------------+ | | OT Zone Edge Zone | | PLC/SCADA Linux/Docker | | Sensors AI Services

Security controls include:

  • device certificates
  • secure boot
  • signed firmware
  • encrypted communications
  • least privilege
  • network segmentation
  • firewalling
  • vulnerability management
  • security logging
  • backup/recovery.

34. Predictive-Maintenance Analytics

The analytics chain is:

Sensor Data ↓ Synchronization ↓ Data Quality ↓ Signal Processing ↓ Feature Extraction ↓ AI/ML ↓ Anomaly Detection ↓ Fault Diagnosis ↓ RUL / Prognostics ↓ Maintenance Recommendation ↓ CMMS

Academic surveys emphasize that predictive maintenance is multidisciplinary and combines sensing, data processing, machine learning, distributed computing and engineering knowledge. ScienceDirect

35. Feature Engineering

Time-domain

  • RMS
  • peak
  • peak-to-peak
  • crest factor
  • kurtosis
  • skewness.

Frequency-domain

  • FFT
  • band energy
  • sidebands
  • harmonics
  • spectral kurtosis.

Envelope

Useful for bearing-related fault signatures.

Electrical

  • current harmonics
  • voltage distortion
  • motor-current signatures.

Trend

  • temperature growth
  • vibration growth
  • operating hours
  • load history.

36. Machine-Learning Architecture

Potential methods include:

Method

Application

Thresholds

Basic alarms

SPC

Stable processes

Regression

Degradation

Random Forest

Fault classification

SVM

Classification

Neural Networks

Complex patterns

Autoencoders

Anomaly detection

LSTM/Temporal models

Time-series behavior

Physics-informed models

Known degradation physics

Hybrid models

Engineering + ML

Recent literature continues to show substantial use of conventional ML alongside deep-learning and hybrid approaches, while highlighting the gap between standardized datasets and real industrial deployment. MDPI

37. AI Model Governance

Each production model should have:

  • model ID
  • version
  • training-data provenance
  • preprocessing specification
  • feature specification
  • validation results
  • deployment target
  • drift monitoring
  • rollback mechanism
  • retraining policy
  • human-review policy.

AI should therefore become a governed engineering artifact.

38. Maintenance Decision Architecture

An AI prediction is not itself a maintenance action.

A useful alert should include:

Asset Location Failure Mode Severity Confidence Trend Supporting Measurements Recommended Action Priority Technician Skill Spare Parts Historical Evidence

The output should feed the organization's maintenance process.

39. Digital Twin Opportunity

The architecture can eventually support a digital twin.

Physical Asset ↕ Digital Representation ↕ Telemetry ↕ Simulation ↕ AI ↕ Maintenance

The digital twin can combine:

  • physical asset model
  • operational state
  • sensor history
  • failure modes
  • simulation
  • AI predictions
  • maintenance history.

The virtual platform therefore becomes an important foundation for future digital-twin development.

40. Verification and Validation

Verification must occur at multiple levels.

Level

Example

Requirement

Traceability

Model

SysML consistency

Architecture

SystemC/TLM

Software

Unit tests

API

Postman

Behavior

Cucumber

Linux

QEMU

Hardware

RTL

FPGA

Prototype

System

HIL

Security

Threat testing

Field

Industrial pilot

41. Hardware-in-the-Loop

HIL should combine:

Real Sensor | Real ECU | Real RTOS | Real FPGA | Simulated Asset | Simulated Network | Simulated Fault

This permits controlled testing of:

  • sensor faults
  • network outages
  • processor overload
  • timing violations
  • abnormal vibration
  • thermal events
  • communication failures.

42. Fault Injection

Fault injection should be a formal part of the methodology.

Examples:

Sensor disconnected Sensor saturated Sensor drift ADC failure DMA failure Memory exhaustion CPU overload Network loss Packet corruption AI service unavailable Database unavailable Authentication failure Power interruption

The system's response should be defined through SysML state models and BDD scenarios.

43. Observability

The production architecture should measure:

Metrics

  • CPU utilization
  • memory utilization
  • sensor rate
  • queue depth
  • API latency
  • AI latency
  • dropped messages.

Logs

  • security events
  • sensor failures
  • service failures
  • model decisions
  • update events.

Traces

Sensor ↓ Gateway ↓ API ↓ Feature Service ↓ AI ↓ Alert ↓ CMMS

This makes operational troubleshooting substantially easier.

44. Reference Toolchain

Area

Tools/Technologies

MBSE

SysML, SysML v2, Sparx EA

Architecture

UML, BPMN

Simulation

SystemC/TLM

Virtual Platform

QEMU, SystemC VP

RTOS

FreeRTOS, Zephyr, ThreadX

Embedded Linux

Yocto, Buildroot

FPGA

VHDL, Verilog/SystemVerilog

VLSI

RTL, synthesis, STA

Containers

Docker

Orchestration

Docker Compose / appropriate edge platform

APIs

REST, OpenAPI

API testing

Postman

BDD

Cucumber/Gherkin

Testing

pytest and language-specific frameworks

CI/CD

Git-based CI/CD

Security

SAST, SBOM, dependency/container scanning

Industrial protocols

OPC UA, MQTT, Modbus/TCP

AI

Python, PyTorch, scikit-learn, ONNX

Monitoring

Metrics/logs/traces

HIL

DAQ, FPGA, laboratory equipment

The toolchain is deliberately modular. The methodology should not depend on a single vendor.

45. Proposed Sparx EA Model

The EA repository should contain:

Stakeholders ↓ Mission ↓ Use Cases ↓ Requirements ↓ System Blocks ↓ Internal Structure ↓ Behavior ↓ Parametrics ↓ Hardware Allocation ↓ Software Allocation ↓ Cybersecurity ↓ Verification

Additional packages should cover:

SystemC Virtual Platform QEMU RTOS Embedded Linux Docker Microservices REST BDD Cucumber HIL

46. Example Requirement-to-Test Chain

Requirement

REQ-PM-014 The system shall issue a validated bearing-degradation alert within five seconds of the final relevant vibration sample.

Architecture

Sensor ↓ ADC ↓ DMA ↓ RTOS ↓ Feature Extraction ↓ AI ↓ Alert

Simulation

SystemC/TLM evaluates the timing.

Software

Embedded implementation realizes the algorithm.

API

POST /api/v1/alerts

BDD

Scenario: Bearing degradation detected Given normal motor operation When vibration indicates validated degradation Then an alert shall be created within five seconds

Postman

Validate the API.

HIL

Inject vibration condition.

Field

Measure actual operational performance.

This is the proposed executable traceability chain.

47. Research Methodology

The research should use a combination of:

Literature review

Review:

  • MBSE
  • SysML
  • SystemC
  • virtual platforms
  • embedded systems
  • predictive maintenance
  • AI
  • industrial cybersecurity
  • BDD
  • DevOps.

Architecture research

Develop a reference architecture.

Simulation research

Build SystemC/TLM models.

Experimental research

Measure:

  • latency
  • throughput
  • CPU utilization
  • memory
  • bandwidth
  • power
  • inference time.

Prototype research

Develop FPGA/embedded prototype.

Software research

Develop:

  • RTOS software
  • Embedded Linux
  • Docker services
  • REST APIs.

Verification research

Implement:

  • Postman
  • BDD
  • Cucumber
  • HIL.

Field research

Deploy on an industrial asset.

48. Research Metrics

The project should measure:

Hardware

  • CPU utilization
  • FPGA utilization
  • memory
  • power
  • thermal performance.

Software

  • execution time
  • latency
  • reliability
  • code coverage.

Network

  • bandwidth
  • packet loss
  • jitter
  • latency.

AI

  • precision
  • recall
  • F1
  • false-positive rate
  • false-negative rate
  • RUL error.

System

  • sensor-to-alert latency
  • availability
  • recovery time
  • detection rate.

Maintenance

  • avoided failures
  • maintenance lead time
  • false alarms
  • technician acceptance
  • work-order effectiveness.

49. Research Hypotheses

H1

MBSE improves traceability between system requirements and verification artifacts.

H2

SystemC/TLM virtual prototyping reduces late hardware/software architecture changes.

H3

Virtual platforms reduce dependence on physical hardware during early embedded-software development.

H4

A heterogeneous RTOS/Linux architecture provides better separation between deterministic and non-deterministic workloads.

H5

FPGA acceleration improves deterministic processing for high-rate signal-analysis workloads.

H6

Containerized edge services improve deployment repeatability for non-real-time functions.

H7

Contract-first REST API engineering reduces integration defects.

H8

BDD and Gherkin improve communication between domain experts and software/test engineers.

H9

Executable traceability improves verification completeness.

H10

An integrated MBSE/DevSecOps workflow improves industrial product-development quality compared with disconnected engineering workflows.

50. 30-Day Foundation Phase

Activities

  • establish Sparx EA repository
  • define pilot asset
  • interview stakeholders
  • identify failure modes
  • establish requirements
  • establish engineering standards
  • define cybersecurity assumptions.

Deliverables

  • project charter
  • stakeholder model
  • initial SysML model
  • requirements catalogue
  • preliminary architecture
  • initial risk register.

51. 31–60 Day Architecture Phase

Activities

  • system decomposition
  • sensor selection
  • processor selection
  • RTOS architecture
  • Linux architecture
  • network architecture
  • API definition
  • microservice decomposition.

Deliverables

  • architecture baseline
  • interface-control document
  • allocation matrix
  • OpenAPI draft
  • virtual-platform architecture.

52. 61–90 Day Virtual Prototype Phase

Activities

  • SystemC/TLM model
  • QEMU environment
  • Embedded Linux
  • RTOS prototype
  • Docker services
  • API implementation
  • Postman tests.

Deliverables

  • virtual platform
  • firmware prototype
  • Linux image
  • container stack
  • API test collection.

53. 91–120 Day BDD and Integration Phase

Activities

  • Gherkin scenarios
  • Cucumber automation
  • CI/CD
  • security scanning
  • integration tests
  • fault injection.

Deliverables

  • executable requirements
  • BDD test suite
  • CI pipeline
  • security baseline
  • integration report.

54. 121–150 Day Hardware Phase

Activities

  • FPGA prototype
  • sensor hardware
  • embedded controller
  • HIL
  • performance measurements.

Deliverables

  • hardware prototype
  • FPGA implementation
  • HIL environment
  • hardware verification report.

55. 151–180 Day Industrial Pilot

Activities

  • deploy selected equipment
  • collect operational data
  • validate AI
  • connect CMMS
  • measure maintenance outcomes.

Deliverables

  • field-validation report
  • KPI report
  • model-governance package
  • research paper
  • industrial demonstration.

56. Roles of IAS-Research, KeenComputer and KeenDirect

IAS-Research

IAS-Research should function as the research, architecture and intellectual-property organization.

Responsibilities:

  • MBSE methodology
  • research
  • standards analysis
  • architecture
  • SystemC/TLM research
  • AI research
  • VLSI research
  • academic publication
  • conference papers
  • technology assessment.

KeenComputer

KeenComputer should function as the engineering and implementation organization.

Responsibilities:

  • embedded engineering
  • Linux
  • RTOS
  • FPGA
  • software
  • Docker
  • APIs
  • cloud/edge deployment
  • cybersecurity
  • monitoring
  • DevOps
  • managed industrial solutions.

KeenDirect

KeenDirect should function as the commercialization and customer-engagement organization.

Responsibilities:

  • industrial workshops
  • product packaging
  • training
  • demonstrations
  • customer discovery
  • channel development
  • solution briefs
  • pilot commercialization
  • recurring service offerings.

57. Strategic Partnership Model

The organizations form a lifecycle:

IAS-Research Research / IP | v Architecture | v KeenComputer Engineering / Build | v Deployment | v KeenDirect Commercialization / Market | v Industrial Client | v Operational Data | +----------+ | v IAS-Research New Research

This creates a feedback loop between research, engineering and market needs.

58. Commercial Solution Packages

The methodology can be productized into several offerings.

Package 1 — IIoT Readiness Assessment

  • asset assessment
  • sensor assessment
  • network assessment
  • cybersecurity assessment
  • predictive-maintenance opportunity analysis.

Package 2 — MBSE Architecture Package

  • SysML model
  • requirements
  • architecture
  • traceability
  • verification plan.

Package 3 — Virtual Prototype

  • SystemC/TLM
  • QEMU
  • virtual platform
  • RTOS/Linux environment.

Package 4 — Edge AI Prototype

  • sensor acquisition
  • feature extraction
  • AI
  • Docker
  • APIs.

Package 5 — Industrial Pilot

  • hardware
  • edge computing
  • analytics
  • dashboard
  • CMMS integration.

Package 6 — Managed Predictive Maintenance

Recurring service:

  • monitoring
  • model maintenance
  • cybersecurity
  • software updates
  • reporting
  • engineering support.

59. SWOT Analysis

Strengths

Weaknesses

Multidisciplinary

Significant engineering effort

Traceability

Requires MBSE discipline

Virtual prototyping

Modeling expertise required

Reusable architecture

Initial investment

Open-source components possible

Integration complexity

Strong research potential

Requires industrial datasets

Opportunities

Threats

Industry 4.0

Vendor lock-in

Industrial AI

Cybersecurity attacks

Edge computing

AI model drift

Digital twins

Poor sensor data

SME modernization

Resistance to change

Research commercialization

Long industrial sales cycles

60. Expected Research Contributions

The project can produce at least five research contributions.

Contribution 1

A traceable SysML-to-SystemC/TLM methodology.

Contribution 2

An RTOS + Embedded Linux + Docker edge architecture.

Contribution 3

An executable requirements methodology using BDD/Gherkin.

Contribution 4

A virtual-platform-to-HIL predictive-maintenance development process.

Contribution 5

A reusable industrial predictive-maintenance reference architecture.

61. Proposed Publications

Paper 1

A Traceable SysML-to-SystemC/TLM Methodology for Hardware–Software Co-Design of Industrial IoT Predictive-Maintenance Systems

Contribution:

  • SysML
  • SystemC
  • virtual prototypes
  • requirements traceability.

Paper 2

An RTOS, Embedded Linux and Containerized Edge Architecture for Industrial Predictive Maintenance

Contribution:

  • heterogeneous computing
  • deterministic processing
  • Docker
  • microservices.

Paper 3

Executable Requirements for Industrial Cyber-Physical Systems Using SysML, BDD, Cucumber and Gherkin

Contribution:

  • requirements
  • behavior
  • automation
  • verification.

Paper 4

Virtual-Platform and QEMU-Based Development of Embedded AI Systems for Industrial Condition Monitoring

Contribution:

  • QEMU
  • embedded Linux
  • virtual hardware
  • AI.

Paper 5

Model-Based Performance Co-Design of FPGA Accelerators for Edge Predictive Maintenance

Contribution:

  • FPGA
  • SystemC/TLM
  • signal processing
  • AI acceleration.

Paper 6

IEC 62443-Aligned DevSecOps for Containerized Industrial Edge Computing

Contribution:

  • industrial cybersecurity
  • containers
  • API security
  • CI/CD.

62. Conference Strategy

Potential venues include:

  • Design Automation Conference (DAC)
  • ASP-DAC
  • IEEE INDIN
  • IEEE ETFA
  • IEEE IECON
  • INCOSE International Symposium
  • IEEE VLSI/SoC conferences
  • IEEE Embedded Systems conferences.

The work should be divided by contribution rather than submitting the same material repeatedly.

63. Recommended Academic and Industrial References

Standards and industrial references

  1. OMG, Systems Modeling Language (SysML) Version 2.0, September 2025. OMG identifies SysML v2 as the current next-generation systems modeling language and provides normative language and transformation specifications. Object Management Group
  2. ISO/IEC/IEEE 42010:2022, Software, systems and enterprise — Architecture description. ISO
  3. IEEE Std 1666-2023, IEEE Standard for Standard SystemC Language Reference Manual. IEEE Standards Association
  4. Accellera Systems Initiative, Transaction-Level Modeling (TLM) 2.0 Language Reference Manual.
  5. IEC 62443-1-1, Industrial communication networks — Network and system security — Terminology, concepts and models. webstore.iec.ch
  6. IEC 62443-2-1:2024, Security program requirements for IACS asset owners. webstore.iec.ch
  7. IEC 62443-2-4:2023, Security program requirements for IACS service providers. webstore.iec.ch
  8. IEC 62443-3-3, System security requirements and security levels. webstore.iec.ch
  9. IEC 62443-4-1:2018, Secure product development lifecycle requirements. webstore.iec.ch
  10. IEC 62443-4-2:2019, Technical security requirements for IACS components. webstore.iec.ch
  11. IEC PAS 62443-1-6:2025, Application of the 62443 series to the Industrial Internet of Things. webstore.iec.ch
  12. Sparx Systems, Enterprise Architect — MBSE and SysML documentation. Sparx Systems
  13. QEMU Project, QEMU System Emulation Documentation. QEMU
  14. Yocto Project, Project Overview and Embedded Linux Development Framework. Yocto Project
  15. Cucumber, Gherkin Reference and Documentation. Cucumber
  16. Postman, API Testing and Automation Documentation. Postman Docs

64. Academic References

MBSE

Madni, A. M., and Sievers, M. (2018). Model-based systems engineering: Motivation, current status, and research opportunities. Systems Engineering. The paper discusses MBSE's role in complexity management, consistency, traceability, verification and validation. INCOSE Online Library

Friedenthal, S., Moore, A., and Steiner, R. (2015). A Practical Guide to SysML: The Systems Modeling Language. Morgan Kaufmann. ScienceDirect

Friedenthal, S., Moore, A., and Steiner, R. A Practical Guide to SysML, later editions and associated systems-engineering materials.

SystemC and TLM

Black, D. C., Donovan, J., Bunton, B., and Keist, A. SystemC: From the Ground Up, 2nd ed., Springer. The book emphasizes SystemC, TLM 2.0 and system-level hardware/software modeling. Springer Link

Ghenassia, F., ed. Transaction-Level Modeling with SystemC, Springer.

Staunstrup, J., and Wolf, W. Hardware/Software Co-Design: Principles and Practice.

Predictive Maintenance

Zonta, T., da Costa, C. A., Righi, R. R., de Lima, M. J., da Trindade, E. S., and Li, G. P. (2020). Predictive maintenance in the Industry 4.0: A systematic literature review. Computers & Industrial Engineering, 150, 106889. The review emphasizes the multidisciplinary nature of predictive maintenance and its relationship with AI and distributed computing. ScienceDirect

Mallioris, P., Aivazidou, E., and Bechtsis, D. (2024). Predictive maintenance in Industry 4.0: A systematic multi-sector mapping. CIRP Journal of Manufacturing Science and Technology, 50, 80–103. DOI

Hector, I., and Panjanathan, R. (2024). Predictive maintenance in Industry 4.0: a survey of planning models and machine learning techniques. PeerJ Computer Science, 10, e2016. PubMed Central (PMC)

Paradigm shift for predictive maintenance and condition monitoring from Industry 4.0 to Industry 5.0: A systematic review, challenges and case study (2024), Results in Engineering, 24, 102935. This work examines the integration of ML, IoT, big data and digital twins and includes a pump-oriented case study. DOI

65. Industrial Software References

The methodology should additionally draw upon established industrial practices in:

  • real-time embedded systems
  • Linux device development
  • Yocto/OpenEmbedded
  • FPGA development
  • REST/API engineering
  • container security
  • CI/CD
  • DevSecOps
  • software testing
  • observability.

Relevant engineering references include:

  • Real-Time Systems literature covering scheduling and deterministic execution.
  • Embedded Linux Development Using Yocto Projects and related Yocto documentation.
  • Docker and OCI container specifications.
  • OpenAPI specification documentation.
  • Cucumber/Gherkin documentation.
  • Postman API-testing documentation.
  • IEEE software-engineering standards.
  • NIST cybersecurity guidance.
  • IEC 62443 industrial cybersecurity standards.

66. Limitations

The methodology has limitations.

66.1 Modeling cost

Detailed MBSE requires training and discipline.

66.2 Model fidelity

SystemC/TLM models are abstractions and cannot replace all RTL and physical tests.

66.3 QEMU limitations

QEMU emulation does not automatically reproduce every electrical or timing characteristic of the final hardware.

66.4 AI limitations

Predictive models remain dependent on:

  • data quality
  • representative failure data
  • sensor quality
  • operating conditions
  • model drift.

66.5 Cybersecurity

No architecture can guarantee absolute cybersecurity.

66.6 Industrial deployment

Real plants contain legacy systems and undocumented interfaces that can complicate integration.

67. Industrial Risk Register

Risk

Impact

Mitigation

Poor sensor data

High

Calibration and data-quality monitoring

Incorrect architecture

High

SystemC/TLM and architecture reviews

Hardware/software mismatch

High

Virtual platform

AI false alarms

High

Human review and validation

Network outage

Medium

Edge autonomy

Cyberattack

Very high

IEC 62443 architecture

Container vulnerability

High

Image scanning and patching

API incompatibility

Medium

OpenAPI contracts

Requirement ambiguity

High

BDD/Gherkin

Hardware delay

High

QEMU/virtual platforms

Model drift

High

Continuous monitoring

Technician rejection

High

Human-centered workflow

68. Key Performance Indicators

The pilot should establish quantitative KPIs.

Engineering

  • 90% requirement traceability
  • reduction in interface defects
  • reduction in late architecture changes
  • virtual prototype completed before final hardware release.

Embedded

  • CPU utilization
  • memory utilization
  • deterministic latency
  • power consumption.

Software

  • test coverage
  • API reliability
  • deployment repeatability
  • mean time to recovery.

AI

  • precision
  • recall
  • F1
  • false alarms
  • missed failures
  • RUL accuracy.

Operations

  • asset availability
  • maintenance lead time
  • downtime reduction
  • technician response
  • work-order effectiveness.

69. Overall Engineering Lifecycle

The complete lifecycle is:

BUSINESS NEED | v SYSTEM REQUIREMENTS | v SysML / EA MBSE | v SYSTEM ARCHITECTURE | +-------+-------+ | | v v SystemC/TLM UML | | v v Virtual Platform Software Design | +---+---+ | | v v QEMU FPGA/VLSI | v Embedded Linux | +------+ | | RTOS Docker | | | Microservices | | +---+--+ | REST/OpenAPI | Postman | BDD/Cucumber/Gherkin | CI/CD | DevSecOps | HIL | Physical Pilot | CMMS/ERP | Maintenance Outcome | Research Data | New Models

70. Conclusion

Industrial predictive maintenance should not be regarded as a narrow machine-learning application.

It is an integrated cyber-physical engineering discipline.

A production-quality solution requires coordinated engineering of:

  • the physical asset
  • sensors
  • analog electronics
  • ADC/data acquisition
  • embedded processors
  • RTOS
  • FPGA/VLSI
  • embedded Linux
  • virtual platforms
  • QEMU
  • SystemC/TLM
  • Docker
  • microservices
  • REST APIs
  • industrial protocols
  • AI/ML
  • cybersecurity
  • testing
  • maintenance workflows.

The proposed methodology establishes a coherent engineering chain:

SysML → Sparx EA → SystemC/TLM → Virtual Platform → QEMU → RTOS/Embedded Linux → FPGA/VLSI → Docker/Microservices → REST/OpenAPI → Postman → BDD/Cucumber/Gherkin → CI/CD/DevSecOps → HIL → Industrial Pilot.

The most important conceptual contribution is executable traceability.

A requirement should not remain merely as a line in a requirements document. It should progressively become:

Requirement ↓ Architecture ↓ Simulation ↓ Implementation ↓ API ↓ Behavior ↓ Automated Test ↓ HIL ↓ Field Evidence

This creates a bridge between systems engineering, hardware engineering, embedded software, AI, software engineering and industrial operations.

For IAS-Research, the methodology provides a research platform for publications, reference architectures, SystemC/TLM studies, VLSI/FPGA research, AI research and MBSE methodologies.

For KeenComputer, it provides an engineering platform for embedded systems, Linux/RTOS development, virtual platforms, industrial IoT, APIs, microservices, cybersecurity, DevOps and managed industrial solutions.

For KeenDirect, it creates a commercial platform for industrial assessments, MBSE consulting, predictive-maintenance pilots, training, engineering packages and recurring technology services.

The immediate research and industrial objective should therefore be a motor-pump predictive-maintenance demonstrator incorporating:

  1. vibration and temperature sensing;
  2. MCU/RTOS acquisition;
  3. FPGA/DSP signal processing where justified;
  4. Embedded Linux edge computing;
  5. QEMU-based software development;
  6. SystemC/TLM virtual prototyping;
  7. Dockerized analytics and API services;
  8. REST/OpenAPI integration;
  9. Postman API verification;
  10. Gherkin/Cucumber behavioral testing;
  11. CI/CD and DevSecOps;
  12. IEC 62443-oriented cybersecurity;
  13. hardware-in-the-loop fault injection;
  14. AI-based anomaly detection;
  15. CMMS maintenance integration.

The resulting demonstration would provide more than a predictive-maintenance prototype. It would constitute a reusable digital-engineering reference platform capable of supporting academic research, industrial pilots, technology training, and commercialization.

The long-term objective is to establish an IAS-Research–KeenComputer–KeenDirect engineering framework in which the system model, virtual prototype, embedded implementation, software services, AI models, verification evidence and industrial maintenance process form one continuously traceable digital thread.