Details: Category: Consulting Service; By IASR Admin; 20.Sep; Hits: 7

Modern embedded systems are no longer designed as isolated hardware or software products. A smart inverter, automotive diagnostic platform, intelligent sensor, electric vehicle controller, or edge-AI device is a cyber-physical system in which electrical, mechanical, electronic, software, communications, control, artificial intelligence, and operational requirements interact.

This complexity creates a fundamental engineering problem: a change in one domain can propagate through the entire system.

Model-Based Systems Engineering and Hardware–Software Co-Design for Embedded AI Systems

IASR Admin

Research- Engineering

IASR - Engineering & Innovation Comppany

Model-Based Systems Engineering and Hardware–Software Co-Design for Embedded AI Systems

ARM SoCs, QEMU, RTOS, Embedded Linux, TinyML, MATLAB/Simulink and SystemC-TLM

Applications to Smart Inverters and OBD-AI Automotive Diagnostics

Research White Paper

Prepared for: Advanced Embedded Systems, AI and Systems Engineering Research
Domains: MBSE • SysML • Hardware/Software Co-Design • ARM SoC • RTOS • Embedded Linux • TinyML • SystemC-TLM • MATLAB/Simulink • QEMU
Application Domains: Smart Grid • Power Electronics • Automotive Diagnostics • Edge AI • IoT • Cyber-Physical Systems

Abstract

Modern embedded systems are no longer designed as isolated hardware or software products. A smart inverter, automotive diagnostic platform, intelligent sensor, electric vehicle controller, or edge-AI device is a cyber-physical system in which electrical, mechanical, electronic, software, communications, control, artificial intelligence, and operational requirements interact.

This complexity creates a fundamental engineering problem: a change in one domain can propagate through the entire system.

A processor selection affects memory architecture. Memory constraints affect the operating system. The operating system affects scheduling. Scheduling affects control-loop timing. Control-loop timing affects power-electronic performance. AI inference affects CPU utilization, memory bandwidth, thermal behavior, and energy consumption. Communications protocols affect software architecture and cybersecurity. Consequently, hardware/software partitioning must be treated as a system-level engineering decision rather than as a late implementation detail.

Model-Based Systems Engineering (MBSE) provides a method for managing this complexity by placing a coherent system model at the center of requirements, architecture, analysis, design, verification, and lifecycle management. Friedenthal, Moore, and Steiner describe the transition from document-centric engineering toward a model-centered approach intended to improve management of complexity, communication, knowledge capture, design evolution, and engineering traceability.

This paper develops an integrated MBSE and hardware/software co-design framework for embedded intelligent systems. SysML is used to represent requirements, system structure, behavior, interfaces, allocations, constraints, and verification. MATLAB/Simulink is used for dynamic modeling, control-system simulation, plant modeling, algorithm development, and code generation. SystemC/TLM is used for architectural exploration and virtual-platform modeling. QEMU provides processor and platform emulation for ARM-based software development. RTOS technology supports deterministic embedded control, while Embedded Linux supports higher-level networking, storage, security, AI, and application services. TinyML provides an architectural path for executing constrained machine-learning workloads close to sensors and actuators.

Two representative systems are developed conceptually:

A smart inverter, combining power electronics, sensing, digital control, communications, ARM processing, RTOS/embedded Linux, and edge intelligence.
OBD-AI, an automotive diagnostic system combining CAN/OBD-II data, embedded sensing, TinyML, ARM processing, RAG/AI services, diagnostic knowledge, and cloud/edge computing.

The paper proposes a unified engineering flow:

Stakeholder Need → Requirements → SysML Architecture → Functional Allocation → MATLAB/Simulink Plant & Control Model → Hardware/Software Partition → SystemC-TLM Architecture → QEMU Virtual Platform → RTOS/Embedded Linux → TinyML/AI → Hardware Prototype → Verification → Digital Thread

The resulting approach is intended to reduce late integration risk and establish traceability between system-level engineering intent and executable hardware/software implementations.

1. Introduction

1.1 The Embedded-System Design Challenge

Embedded systems increasingly combine:

microprocessors and microcontrollers;
ARM Cortex-A, Cortex-R and Cortex-M processors;
FPGA and ASIC components;
sensors and actuators;
real-time operating systems;
Embedded Linux;
device drivers;
communication networks;
control algorithms;
machine learning;
cybersecurity;
cloud services;
human-machine interfaces.

A traditional development process may divide these responsibilities among electrical, electronics, firmware, software, control, AI, and systems engineering teams.

The resulting organizational decomposition is useful, but it creates an engineering danger: local optimization can produce global system problems.

For example:

A machine-learning algorithm may be accurate but too computationally expensive for the selected MCU. A control algorithm may be mathematically correct but fail because the real-time task misses its deadline. A Linux application may work correctly but interfere with deterministic control functions. A processor may provide sufficient computational performance but consume too much energy. A hardware interface may satisfy electrical requirements but not provide sufficient software abstraction.

MBSE provides a mechanism for connecting these decisions.

The SysML approach described by Friedenthal et al. explicitly supports modeling requirements, structure, behavior, properties, flows, constraints, allocations, and verification.

2. Research Objectives

This paper has six objectives.

Objective 1 — Establish an MBSE architecture

Create a SysML-centered system model connecting stakeholder needs, requirements, architecture, behavior, implementation and verification.

Objective 2 — Integrate hardware/software co-design

Treat processor, memory, accelerators, RTOS, Linux, drivers, communication and AI algorithms as interconnected system-design variables.

Objective 3 — Establish simulation before hardware

Use MATLAB/Simulink and SystemC-TLM to explore the system before committing to hardware.

Objective 4 — Establish virtual platforms

Use QEMU and related virtual-platform technology to execute embedded software before physical hardware is available.

Objective 5 — Integrate edge AI

Use TinyML and ARM-optimized inference techniques for local sensing, classification and anomaly detection.

Objective 6 — Demonstrate applicability

Apply the methodology to:

smart inverter engineering;
OBD-AI automotive diagnostics.

3. Model-Based Systems Engineering

3.1 From Documents to Models

A central concept in MBSE is the transition from controlling many disconnected engineering documents toward controlling a coherent system model.

Friedenthal et al. describe MBSE as emphasizing a coherent system model rather than simply producing and controlling documentation about the system. They identify benefits including management of complexity, improved design quality and cycle time, improved communication, knowledge capture and design evolution.

For embedded systems this distinction is particularly important.

A conventional document set might contain:

system requirements;
hardware specifications;
software requirements;
interface-control documents;
timing specifications;
control equations;
test procedures;
AI specifications.

The MBSE alternative connects these artifacts through a model.

4. SysML as the System Architecture Language

SysML provides a graphical modeling language for systems containing combinations of hardware, software, data, people, facilities and other system elements.

The important SysML concepts for embedded co-design include:

SysML concept	Embedded-system application
Requirement	Timing, safety, power, accuracy, latency
Block	CPU, MCU, inverter, CAN controller, sensor
Internal Block	Physical architecture and interfaces
Activity	Control and diagnostic processing
State Machine	Operating modes and fault states
Sequence	Processor/software interaction
Parametric Model	Electrical, thermal and timing constraints
Allocation	Function → hardware/software
Constraint	Timing, memory, energy and performance
Verification	Test case → requirement
Traceability	Requirement → design → implementation → test

The book specifically describes requirements modeling, satisfaction and verification relationships, allocation, parametrics, activities, interactions and state machines as core SysML capabilities.

5. The MBSE Digital Thread

A useful embedded-system digital thread can be represented as:

This is more than a documentation hierarchy.

It becomes an engineering traceability mechanism.

6. Requirements Engineering

A smart inverter or OBD-AI system should begin with stakeholder requirements rather than processor selection.

Friedenthal et al. describe the systems-engineering process as eliciting stakeholder needs, specifying functionality and interfaces, synthesizing alternatives, analyzing alternatives, and maintaining traceability from goals through requirements and verification.

For an embedded AI system, requirements can be divided into:

Functional

What must the system do?

Performance

How fast must it respond?

Physical

What size, weight, power and thermal limitations exist?

Interface

How does it communicate with sensors, actuators and external systems?

Safety

What must happen during failures?

Security

How must communication, firmware and data be protected?

AI

What accuracy, latency and memory limits apply?

Lifecycle

How will the device be updated, diagnosed and maintained?

7. Hardware/Software Co-Design

7.1 Co-Design Principle

Hardware/software co-design asks:

Which system functions should be implemented in hardware, firmware, RTOS tasks, Linux applications, accelerators or remote/cloud services?

This is fundamentally an architectural optimization problem.

A function can potentially be implemented in:

The correct allocation depends on:

latency;
determinism;
energy;
memory;
computational complexity;
safety;
cybersecurity;
connectivity;
updateability;
cost.

SysML allocation is particularly useful because behavior can be allocated to physical system elements and requirements can be allocated across the architecture. The SysML reference describes functional allocation and allocation between structural hierarchies as mechanisms for representing these relationships.

8. ARM SoC Architecture

ARM provides a particularly useful architecture for this design methodology because ARM systems span different processing profiles.

Cortex-M

Suitable for:

deterministic control;
sensor acquisition;
low-power operation;
motor control;
power conversion;
TinyML.

Cortex-R

Suitable for:

real-time applications;
safety-oriented processing;
deterministic control environments.

Cortex-A

Suitable for:

Embedded Linux;
networking;
graphical interfaces;
databases;
containerized applications;
higher-level AI;
gateways.

A modern intelligent device can therefore use a heterogeneous architecture:

9. RTOS Architecture

An RTOS should be used when timing and determinism are system requirements rather than merely implementation preferences.

Typical RTOS functions include:

task scheduling;
interrupt handling;
timers;
synchronization;
inter-task communication;
device drivers;
memory management;
watchdog handling.

Zephyr, for example, supports ARM architectures ranging across Cortex-M, Cortex-A and Cortex-R families and is explicitly designed for resource-constrained embedded systems. (docs.zephyrproject.org)

An RTOS architecture can therefore be represented in SysML as:

10. Embedded Linux

Embedded Linux provides a complementary environment for functions that require:

networking;
storage;
web interfaces;
databases;
containers;
cybersecurity services;
remote management;
complex AI frameworks;
high-level diagnostics.

The architecture can therefore separate deterministic control from complex application processing.

This separation is particularly useful for smart inverters and automotive systems.

11. QEMU as a Virtual Development Platform

QEMU can emulate ARM systems, including both 32-bit and 64-bit ARM processors and selected Cortex-M-class targets. (QEMU)

QEMU system emulation provides a virtual machine containing CPU, memory and emulated devices, allowing software to execute without the final physical platform. (QEMU)

This makes QEMU useful for:

bootloader development;
Embedded Linux development;
driver development;
RTOS testing;
CI/CD;
regression testing;
virtual hardware development;
debugging.

The development sequence becomes:

QEMU also supports device emulation and includes facilities relevant to embedded development, including CAN-related device support. (QEMU)

12. SystemC and Transaction-Level Modeling

SystemC provides a modeling environment for system architecture exploration.

Transaction-Level Modeling (TLM) abstracts communication away from low-level signal transitions.

This is valuable when the engineering question is:

Can the architecture meet its performance requirements?

rather than:

What is the exact value of every pin at every clock cycle?

Accellera identifies TLM applications including architectural exploration, performance analysis, virtual platforms, software development and functional verification. (accellera.org)

SystemC is therefore positioned between system architecture and implementation.

System Requirement | v SysML Architecture | v SystemC-TLM | +--> CPU model +--> Memory +--> Bus +--> DMA +--> Peripheral +--> Accelerator | v Performance Analysis

The current SystemC ecosystem includes TLM support, and IEEE 1666-2023 defines the SystemC language standard. (accellera.org)

13. MATLAB and Simulink

MATLAB/Simulink provides the complementary mathematical and dynamic-system environment.

Simulink supports:

multidomain modeling;
dynamic simulation;
control-system design;
signal processing;
automatic code generation;
continuous testing and verification. (MathWorks)

The model-based design process can be:

MathWorks describes model-based design as a process in which a system model becomes central to development and supports simulation, test-bench generation and automatic code generation. (MathWorks)

14. Simulink-to-Embedded Implementation

A critical advantage is the ability to connect the mathematical model to implementation.

Code-generation guidelines become important because modeling choices affect generated code efficiency and behavior. MathWorks provides specific guidance for embedded-system code generation and deployment. (MathWorks)

Code-generation technologies can target C/C++, FPGA/HDL and other implementation technologies depending on the development environment. (MathWorks)

15. TinyML

TinyML moves machine-learning inference toward constrained embedded devices.

The architectural objective is not to reproduce a large cloud AI system on a microcontroller.

Instead, TinyML is appropriate for narrowly defined tasks such as:

anomaly detection;
signal classification;
predictive maintenance;
sensor-event detection;
vibration classification;
current waveform classification;
automotive fault classification.

The basic architecture is:

16. ARM CMSIS-NN

ARM's CMSIS-NN provides optimized neural-network kernels intended to reduce execution cost and memory footprint on Cortex-M processors. It includes implementations of operations such as convolution, fully connected layers, pooling, activation and recurrent operations. (keil.arm.com)

This creates a useful TinyML implementation path:

CMSIS provides standardized interfaces and software components intended to simplify reuse across Cortex-M devices. (arm.com)

17. Integrated MBSE Toolchain

The complete methodology can be represented as follows:

18. Case Study I — Smart Inverter

18.1 System Context

A smart inverter converts electrical energy while simultaneously providing monitoring, control, communication and potentially grid-support functionality.

A modern architecture may include:

DC source;
DC-link capacitor;
power semiconductor bridge;
gate drivers;
voltage sensors;
current sensors;
protection circuits;
DSP/MCU;
ARM processor;
RTOS;
communications;
grid interface;
optional Embedded Linux gateway;
edge AI.

19. Smart Inverter MBSE Architecture

A SysML block decomposition could contain:

20. Smart-Inverter Functional Model

The functional flow is:

This closed-loop structure is naturally modeled in Simulink.

21. Smart-Inverter Simulink Model

A representative model consists of:

Additional models can represent:

grid disturbances;
voltage sag;
harmonics;
current limits;
sensor faults;
temperature;
switching losses;
DC-link disturbances;
communication delays.

This creates a virtual prototype before hardware construction.

22. Smart-Inverter Hardware/Software Partition

A possible allocation is:

Function	Implementation
PWM generation	MCU peripheral
Fast current loop	Cortex-M/RTOS
Protection	Hardware + MCU
Sensor acquisition	ADC/DMA
Grid synchronization	MCU
Fault logging	RTOS
Ethernet	Linux/SoC
Web interface	Embedded Linux
Long-term analytics	Linux/cloud
Anomaly detection	TinyML
Fleet analytics	Cloud

The exact partition should be determined through requirements and trade studies rather than predetermined by technology preference.

23. Smart-Inverter SystemC-TLM Model

SystemC-TLM can model:

ARM processor;
memory;
bus;
DMA;
ADC interface;
PWM peripheral;
communication interface;
AI accelerator.

Example:

+-----------------------------+ | ARM SoC Model | | | | CPU ---- Bus ---- Memory | | | | | | | +-- DMA | | | | | +-- PWM | | +-- ADC | | +-- CAN/Ethernet | | +-- AI Accelerator | +-----------------------------+

The objective is to determine whether the architecture can meet:

control latency;
memory requirements;
bus utilization;
CPU utilization;
AI inference time;
communication requirements.

24. Smart-Inverter QEMU Development

Once the processor architecture is defined, QEMU can provide a software-development environment.

The development team can therefore begin software development before all physical hardware is available.

25. Smart-Inverter TinyML

TinyML can monitor electrical signals for patterns associated with:

abnormal current;
unusual voltage behavior;
thermal stress;
switching anomalies;
sensor degradation;
mechanical cooling problems;
emerging faults.

The model should not replace deterministic protection.

Instead:

Safety-critical protection remains explicitly engineered and verified.

AI can provide an additional diagnostic or predictive layer.

26. Case Study II — OBD-AI

26.1 System Objective

OBD-AI is an intelligent automotive diagnostic architecture designed to combine:

OBD-II;
CAN;
vehicle sensors;
diagnostic trouble codes;
service manuals;
diagnostic procedures;
machine learning;
retrieval-augmented generation;
edge computing;
cloud services.

The system therefore combines deterministic automotive communication with probabilistic AI reasoning.

27. OBD-AI System Architecture

28. OBD-AI MBSE Model

Stakeholders

vehicle owner;
technician;
service organization;
fleet operator;
engineering organization;
diagnostic-tool developer.

System requirements

Examples include:

acquire CAN/OBD data;
decode supported diagnostic information;
timestamp measurements;
detect abnormal patterns;
identify candidate fault classes;
retrieve relevant technical information;
explain diagnostic evidence;
operate with intermittent connectivity;
protect vehicle and user data.

29. OBD-AI Functional Decomposition

The AI system should preserve the distinction between:

measured evidence → algorithmic inference → retrieved technical information → diagnostic hypothesis.

This is particularly important in safety-sensitive applications.

30. OBD-AI TinyML

TinyML can operate on signals such as:

engine speed;
coolant temperature;
manifold pressure;
throttle position;
oxygen-related measurements where available;
fuel-related parameters;
battery voltage;
transmission parameters;
vibration;
acoustic measurements.

The objective can be anomaly detection rather than direct diagnosis.

For example:

31. OBD-AI RAG Architecture

A higher-level AI subsystem can retrieve information from:

service manuals;
repair procedures;
diagnostic specifications;
wiring information;
component documentation;
DTC databases;
engineering knowledge.

This architecture separates embedded real-time acquisition from higher-level knowledge reasoning.

32. OBD-AI Hardware/Software Allocation

Function	Candidate implementation
CAN acquisition	MCU peripheral + RTOS
Timestamping	MCU hardware
Fast filtering	Cortex-M
TinyML	Cortex-M + CMSIS-NN
Local database	Embedded Linux
RAG engine	Linux/edge server
Cloud synchronization	Linux
Mobile interface	Smartphone
Diagnostic knowledge	Local/cloud
Security	Hardware root + OS security
OTA update	Linux management layer

33. Co-Simulation Architecture

A particularly powerful research direction is coupling the physical-domain model with the computing-domain model.

This allows the research team to investigate interactions between:

plant dynamics;
processor performance;
software scheduling;
communications;
AI inference;
memory;
control-loop timing.

34. Timing as a First-Class System Requirement

Embedded AI systems require explicit timing analysis.

For a control task:

Texecution<TdeadlineT_{execution} < T_{deadline}

For a periodic control loop:

fcontrol=1Tcontrolf_{control} = \frac{1}{T_{control}}

The architecture must ensure that:

Tsensor+Tcompute+Tcommunication+Tactuator<TallowedT_{sensor}+T_{compute}+T_{communication}+T_{actuator} < T_{allowed}

AI introduces another variable:

Ttotal=Tcontrol+TAI+TcommunicationT_{total}=T_{control}+T_{AI}+T_{communication}

This is why AI cannot simply be inserted into an existing embedded architecture without architectural analysis.

35. Memory as a System-Level Constraint

For embedded AI:

Mtotal=Mcode+Mdata+Mstack+Mheap+MmodelM_{total}=M_{code}+M_{data}+M_{stack}+M_{heap}+M_{model}

The model itself can become a significant portion of memory.

Quantization can reduce memory requirements.

For example, an approximate reduction from floating-point representations to integer representations can substantially reduce storage and computational requirements, depending on the model and implementation.

CMSIS-NN specifically targets optimized neural-network execution and reduced memory footprint on Cortex-M processors. (keil.arm.com)

36. Energy-Aware Co-Design

For battery-powered systems:

Esystem=Ecompute+Ememory+Ecommunication+EsensorE_{system}=E_{compute}+E_{memory}+E_{communication}+E_{sensor}

A design should therefore consider whether a computation belongs:

locally;
on an MCU;
on a Cortex-A;
on an NPU;
on a gateway;
in the cloud.

For example:

Simple classification | v Cortex-M TinyML Complex diagnostic reasoning | v Embedded Linux / Edge Large knowledge retrieval | v Server / Cloud

37. Verification Strategy

MBSE should connect requirements to verification.

The traceability chain should be:

Friedenthal et al. emphasize maintaining traceability among stakeholder needs, system requirements, component requirements and verification results as part of design integrity.

38. Verification Levels

A complete embedded system should be verified at multiple levels.

Level 1 — Algorithm Verification

MATLAB/Python/Simulink.

Level 2 — Model Verification

System-level simulation.

Level 3 — Software Unit Testing

C/C++ and RTOS components.

Level 4 — Virtual Platform Testing

QEMU/SystemC.

Level 5 — Hardware-in-the-Loop

Physical controller connected to simulated plant.

Level 6 — Prototype Testing

Actual electronics.

Level 7 — System Validation

Real operating environment.

39. Hardware-in-the-Loop

HIL is particularly valuable for the smart inverter.

The controller can therefore be tested under conditions that might otherwise require expensive or dangerous physical experiments.

40. Continuous Integration for Embedded Systems

The MBSE approach can be connected to DevOps.

A CI pipeline can automatically test:

build;
static analysis;
unit tests;
model tests;
virtual hardware;
regression tests;
AI model integrity;
interface compatibility.

41. Cybersecurity Architecture

Embedded systems should include cybersecurity in the MBSE model rather than add it after implementation.

Relevant components include:

secure boot;
signed firmware;
encrypted communications;
authentication;
key management;
least privilege;
secure OTA;
network segmentation;
logging;
intrusion detection.

For OBD-AI, particular attention should be given to the distinction between:

diagnostic observation

and

vehicle control commands.

The architecture should prevent an analytics system from unintentionally becoming an uncontrolled vehicle-control interface.

42. Fault Management

A SysML state machine can represent system states such as:

This is useful for both smart inverters and automotive systems.

43. Digital Twin Perspective

The combined methodology creates the foundation for a digital twin.

A digital twin can contain:

The model is no longer merely a design artifact.

It becomes an operational engineering asset.

44. Recommended Development Lifecycle

Phase 1 — Concept

Define:

mission;
stakeholders;
operating environment;
use cases;
constraints.

Phase 2 — Requirements

Develop:

functional requirements;
performance requirements;
interfaces;
safety;
cybersecurity;
AI requirements.

Phase 3 — SysML Architecture

Develop:

requirement diagrams;
block definitions;
internal block diagrams;
activities;
state machines;
parametrics;
allocations.

Phase 4 — Simulation

Develop:

MATLAB/Simulink models;
control algorithms;
plant models;
fault models.

Phase 5 — Co-Design

Evaluate:

processor;
memory;
RTOS;
Linux;
AI accelerator;
communications.

Phase 6 — SystemC-TLM

Perform:

architecture exploration;
performance analysis;
memory/bus analysis;
virtual-platform development.

Phase 7 — QEMU

Develop:

boot software;
drivers;
RTOS;
Linux;
applications.

Phase 8 — TinyML

Develop:

dataset;
feature extraction;
model;
quantization;
embedded inference.

Phase 9 — Hardware Prototype

Integrate:

ARM SoC;
sensors;
power electronics;
CAN;
communications.

Phase 10 — HIL

Validate:

timing;
control;
fault response;
AI;
communications.

Phase 11 — System Validation

Validate against real operating conditions.

45. Recommended Toolchain

Engineering Activity	Candidate Technology
Requirements	SysML
System architecture	SysML
Model management	Sparx Enterprise Architect / other SysML tools
Control design	MATLAB
Dynamic simulation	Simulink
Code generation	Embedded Coder
Architecture modeling	SystemC
Transaction modeling	TLM-2.0
ARM virtualization	QEMU
RTOS	Zephyr / FreeRTOS / other RTOS
Embedded Linux	Yocto / Buildroot / Linux
MCU ML	CMSIS-NN / LiteRT Micro-class frameworks
AI development	Python / PyTorch / TensorFlow ecosystem
Source control	Git
CI/CD	GitHub/GitLab/Jenkins
HIL	dSPACE / Speedgoat / custom HIL
Documentation	MBSE model + engineering repository

46. Research Framework

The proposed research framework can be summarized as:

MBCoSE — Model-Based Co-Design Systems Engineering

Layer 1 — Mission

Why does the system exist?

Layer 2 — Requirements

What must it accomplish?

Layer 3 — System Model

What architecture can accomplish it?

Layer 4 — Physical Model

How does the physical system behave?

Layer 5 — Computing Model

How much computation is required?

Layer 6 — Hardware/Software Partition

Where should each function execute?

Layer 7 — Virtual Platform

Can the architecture work before hardware exists?

Layer 8 — Embedded Implementation

Can the software execute on the target?

Layer 9 — AI

Can intelligence operate within resource constraints?

Layer 10 — Verification

Can every requirement be demonstrated?

47. Comparison of the Principal Modeling Environments

Environment	Primary Purpose	Abstraction
SysML	System architecture	System
MATLAB	Mathematics/algorithms	Algorithm
Simulink	Dynamic/physical simulation	System dynamics
SystemC	Architecture exploration	Electronic-system
TLM	Transaction modeling	Communication
QEMU	Processor/platform emulation	Software/platform
RTOS	Real-time execution	Software
Embedded Linux	High-level embedded computing	Software
TinyML	Constrained AI	Algorithm/runtime
ARM SoC	Physical computation	Hardware

The important conclusion is that these tools should not be treated as competing alternatives.

They occupy different abstraction levels.

48. The Multi-Model Engineering Principle

A major architectural insight is:

One system should have multiple models, but those models should remain connected.

For example:

SYSML | +---------+---------+ | | | Plant Software Hardware | | | Simulink QEMU SystemC | | | +---------+---------+ | HIL | Prototype

The MBSE model establishes the engineering context.

The simulation models establish behavior.

The SystemC model establishes architecture.

QEMU establishes software execution.

The physical prototype establishes real-world behavior.

49. Smart Inverter Research Roadmap

A practical research program could proceed through:

Research Project A

SysML architecture of a grid-connected smart inverter.

Research Project B

MATLAB/Simulink control and plant model.

Research Project C

ARM Cortex-M real-time control implementation.

Research Project D

SystemC-TLM model of the processor subsystem.

Research Project E

QEMU-based embedded software environment.

Research Project F

TinyML-based inverter anomaly detection.

Research Project G

Hardware-in-the-loop validation.

Research Project H

Digital-twin architecture.

50. OBD-AI Research Roadmap

Research Project A

SysML model of an OBD-AI system.

Research Project B

CAN/OBD acquisition architecture.

Research Project C

ARM RTOS acquisition firmware.

Research Project D

TinyML anomaly detection.

Research Project E

Embedded Linux diagnostic gateway.

Research Project F

Knowledge graph/RAG diagnostic system.

Research Project G

SystemC/QEMU virtual platform.

Research Project H

Vehicle/HIL testing.

51. Key Research Questions

The framework enables several publishable research questions.

RQ1

How can SysML traceability be maintained from system requirements to executable embedded software?

RQ2

How can SystemC-TLM improve hardware/software partitioning decisions?

RQ3

How accurately can QEMU represent the software-development environment before target hardware exists?

RQ4

What control-loop performance penalty is introduced by different hardware/software allocations?

RQ5

How can TinyML provide useful anomaly detection within strict MCU memory and timing constraints?

RQ6

How should deterministic RTOS functions coexist with Linux and AI workloads?

RQ7

How can Simulink plant models and SystemC computing models be combined for co-simulation?

RQ8

How can MBSE maintain traceability across physical models, software models and AI models?

RQ9

How can the same methodology support both power-electronic systems and automotive diagnostic systems?

52. Engineering Metrics

The proposed framework should measure:

System

requirement coverage;
requirement traceability;
architectural completeness.

Hardware

CPU utilization;
memory utilization;
power;
thermal performance.

Software

execution time;
task latency;
deadline misses;
code size.

AI

accuracy;
precision/recall;
inference latency;
model size;
energy per inference.

Control

settling time;
overshoot;
stability;
harmonic distortion where applicable;
tracking error.

Verification

test coverage;
model coverage;
hardware/software integration defects;
escaped defects.

53. Engineering Governance

MBSE should not become a diagram-production exercise.

The model must answer engineering questions.

A useful rule is:

Every important model element should support a decision, requirement, analysis, implementation or verification activity.

For example:

This preserves engineering value.

54. Organizational Implementation

Friedenthal et al. describe MBSE deployment as an organizational improvement process and emphasize assessing, planning and piloting MBSE capability before broader deployment.

For an engineering organization, an incremental implementation is therefore appropriate.

Stage 1

Create a small SysML pilot.

Stage 2

Connect requirements to architecture.

Stage 3

Connect architecture to simulation.

Stage 4

Connect simulation to implementation.

Stage 5

Connect implementation to automated testing.

Stage 6

Create a reusable engineering model library.

55. Proposed Reference Architecture

The final architecture can be summarized as:

56. Conclusions

The increasing integration of electronics, software, control and artificial intelligence makes traditional discipline-by-discipline engineering increasingly difficult.

Model-Based Systems Engineering provides a system-level framework for managing this complexity.

The central principle is not simply to create SysML diagrams. It is to establish a traceable engineering model connecting requirements, architecture, behavior, analysis, implementation and verification.

The SysML methodology described by Friedenthal, Moore and Steiner provides the foundation for representing system requirements, structure, behavior, constraints, allocations and verification.

For modern embedded systems, that foundation can be extended with specialized engineering environments:

MATLAB/Simulink for physical and control-system modeling;
SystemC/TLM for hardware/software architecture exploration;
QEMU for processor and platform virtualization;
RTOS for deterministic embedded control;
Embedded Linux for complex application and networking workloads;
ARM SoCs for scalable heterogeneous computation;
TinyML/CMSIS-NN for resource-constrained edge intelligence.

The smart inverter demonstrates how this methodology can connect electrical power systems, control algorithms, embedded processors and AI.

The OBD-AI system demonstrates how the same methodology can connect CAN/OBD data acquisition, deterministic embedded software, TinyML, Linux-based computing and knowledge-based AI.

The most important architectural principle is therefore:

Model the system first, partition the system deliberately, simulate before implementation, virtualize the computing platform, and verify the complete hardware/software system against traceable requirements.

This approach turns MBSE from a documentation methodology into an engineering integration framework for cyber-physical and AI-enabled embedded systems.

57. Recommended References and Resources

57.1 MBSE and SysML

Sanford Friedenthal, Alan Moore, Rick Steiner, A Practical Guide to SysML: The Systems Modeling Language, Third Edition, Morgan Kaufmann/Elsevier.

The supplied reference is particularly relevant because its structure covers systems engineering, MBSE, SysML diagrams, blocks, parametrics, activities, interactions, state machines, use cases, requirements, allocations, MBSE methods, model/tool integration and organizational deployment.

OMG SysML Specification.
INCOSE Systems Engineering Body of Knowledge.
ISO/IEC/IEEE 15288 — Systems and software engineering — System life cycle processes.

57.2 MATLAB/Simulink

MathWorks, Simulink Documentation — Simulation and Model-Based Design. Simulink supports system-level modeling, simulation, automatic code generation and continuous verification for embedded systems. (MathWorks)

MathWorks, Model-Based Design with Simulink. (MathWorks)

MathWorks, Code Generation. (MathWorks)

57.3 SystemC and TLM

Accellera Systems Initiative, SystemC Language Working Group. (accellera.org)

Accellera Systems Initiative, SystemC TLM Working Group. (accellera.org)

IEEE Std. 1666 — SystemC Language Reference Manual.

IEEE Std. 1666.1 — SystemC AMS.

57.4 QEMU

QEMU Project, System Emulation Documentation. (QEMU)

QEMU Project, ARM System Emulator. (QEMU)

QEMU Project, Emulation Documentation. (QEMU)

57.5 ARM and Embedded AI

Arm, CMSIS. (arm.com)

Arm, CMSIS-NN. (keil.arm.com)

Arm, Cortex-M Architecture and Developer Resources. (arm.com)

57.6 RTOS

Zephyr Project Documentation, Introduction. (docs.zephyrproject.org)

Zephyr Project Documentation, Cortex-M Developer Guide. (docs.zephyrproject.org)

FreeRTOS documentation and reference materials.

58. Suggested Research Software Repository Structure

A practical Git repository for this research could use:

This structure allows the system model, simulation models, virtual platform, firmware, Linux software and AI models to evolve as one engineering program.

59. Final Research Proposition

The proposed research can ultimately be formulated as:

MBSE + Hardware/Software Co-Design + SystemC-TLM + QEMU + MATLAB/Simulink + RTOS + Embedded Linux + TinyML provides a unified engineering methodology for developing complex ARM-based cyber-physical systems before and through physical implementation.

The smart inverter and OBD-AI systems provide two complementary validation domains:

Smart Inverter

Physics + Power Electronics + Control + ARM + RTOS + AI

OBD-AI

Vehicle + CAN/OBD + ARM + RTOS + TinyML + Linux + RAG/AI

Together they demonstrate how a common MBSE foundation can support both real-time physical control systems and AI-enabled diagnostic systems while preserving requirements traceability, architectural reasoning, simulation, virtual prototyping and verification.

IASR is a Learning Organization- as described by Peter Senge of MIT-SLOAN. IASR stands for International Alliance Systems Research (IASR). We are a group of Scientist, Researcher and Engineers engaged in solving industrial problems.

Contact Us

IASR - Engineering and Innovation