By Guy Rouleau, Consulting Advanced Support Engineer, and Jason Ghidella, Sr. Principal Technologist, MathWorks

AI coding agents are becoming part of engineering workflows, including the way teams build, test, and refine models. But their value is not simply faster model creation. An agent may generate models, scripts, and tests that execute successfully, while missing the structure, discipline, and constraints required for real engineering systems.

That is the hidden friction in AI-assisted Model-Based Design. More output does not automatically create more clarity. The hard part is keeping engineering intent aligned from specification through implementation and test, so models reflect physical assumptions, component boundaries, parameters, interfaces, and expected behavior in ways engineers can review, verify, and maintain.

A structured agentic workflow can help close that gap. The goal is not to remove the engineer from the workflow. The goal is to keep the engineer in the lead while giving the AI agent enough context, tool access, and workflow guidance to contribute usefully.

In this context, AI-assisted engineering is the broader shift, while agentic AI is the practical mechanism: AI agents that can use engineering tools, follow structured workflows, and help move work from intent to model and test. But for engineering teams, the agent also needs to be grounded. That means giving it access to the context that defines the workflow: models, parameters, interfaces, assumptions, tests, and Model-Based Design practices. Engineering quality still depends on more than producing something that executes.

In Model-Based Design workflows, the important questions go beyond whether the model runs. Does the model reflect the intended system behavior? Are the assumptions visible? Are the parameters defined in a way that can be reviewed and reused? Are the interfaces clear? Are the tests connected to expected behavior?

Those questions are where unstructured AI assistance can struggle. A generic software pattern may be useful in many coding contexts, but engineered systems require discipline around physical behavior, system decomposition, verification, and long-term maintainability. If those elements are not made explicit, an AI agent can move quickly while carrying ambiguity forward.

The challenge, then, is how to give AI agents enough engineering context to contribute in a structured and reviewable way. In Simulink workflows, that means connecting the agent not just to model generation tasks, but to the broader Model-Based Design process: system structure, parameters, interfaces, assumptions, verification workflows, and expected behavior. Approaches built around this idea aim to make engineering intent explicit. Whether that intent actually survives contact with a real system still needs to be shown.

To see what it takes to ground an AI agent in a real engineering context, it helps to start with a system where assumptions, structure, and tests must stay aligned. The disk‑brake thermal model provides a concrete test of this idea.

Disk-brake thermal modeling: from engineering intent to testable evidence

A disk-brake thermal model is simple enough to understand quickly but demanding enough to expose where AI-assisted workflows can lose engineering intent.  Capturing heat transfer behavior requires explicit assumptions, clear component boundaries, well‑defined parameters, and tests tied to expected physical behavior. If any of those elements are implicit or disconnected, the model may execute successfully, but could be difficult to review, validate, or trust.

In this example, an AI agent was asked to create a plan for simulating the thermal behavior of typical disk brakes in an average sedan during common driving maneuvers. Figure 1 shows the physical behavior the model is intended to capture.

The point of the workflow was not just that the agent could generate a model. The value was that it created intermediate engineering artifacts that could be reviewed before implementation began.

In this workflow, that structure was enabled by the Simulink Agentic Toolkit, which provides AI agents with access to Simulink models, planning templates, and Model-Based Design context rather than relying on unstructured prompt-and-response interactions.

Planning before building

Before generating the model, the agent produced a structured plan for the disk-brake thermal system. That plan included the system architecture, implementation approach, test plan, assumptions, interfaces, equations, and parameters. Here is the output after a few iterations:

• disk-brake-thermal-system-architecture.md
• disk-brake-thermal-implementation-test-plan.md

The plan is based on a template and contains standard sections such as:

• Executive summary
• Problem statement
• Goals and success metrics
• Assumptions
• Interface
• References

The plan then went into implementation details. Across several iterations, it evolved to include a simple longitudinal vehicle with the brake model, as shown in Figure 2.

The plan also described how the model would be componentized into subsystems and referenced models, including brake hydraulics, vehicle longitudinal dynamics, heat partition, rotor thermal behavior, pad thermal behavior, and related components, as shown in Figure 3.

This planning step is important because it gives engineers something concrete to review before the agent starts building. The model is not created from a single prompt and is not accepted as-is. The workflow creates a visible design intent that can be inspected, corrected, and refined.

The agent also described the equations to be implemented in each component, as shown in Figure 4.

The workflow identified parameters needed by the model, and also produced a parameter list, as shown in Figure 5.

That reviewable trail is what helps ground the AI-assisted workflow. It gives engineers a basis for understanding what was created, why it was created that way, and what needs to be checked before the result can be approved. That makes the workflow more aligned with how engineers typically work. Assumptions, interfaces, equations, and parameters are not hidden inside generated code or model structure. They are surfaced early, where they can be checked.

Implementing the model

Once the plan was reviewed and refined, the agent was instructed to generate the model. The result is shown in Figure 6.

In this case, the first generated model captured the intended structure of the disk-brake thermal example. The model included the vehicle-level inputs, brake hydraulics, heat partitioning, and thermal behavior of the rotor and pad.

The key is not that the agent created a model from a prompt. The model was created from a structured plan that described the system architecture, component responsibilities, equations, parameters, and test intent. That structure helped reduce the risk that the agent produces an artifact that runs but is difficult to understand, extend, or validate.

Parameters were also handled explicitly. The agent initially created a MATLAB script defining the required variables. In a production workflow, those parameters could also be moved into a data dictionary or another controlled data source, depending on team practices.

Testing the result

Testing is where the value of a structured agentic workflow becomes especially clear. The agent not only produces a model. It also produced a test plan that described how individual components and the full system should be validated. Each test was derived directly from the original assumptions and expected behaviors defined during planning, providing a traceable link between engineering intent and observed model behavior.

The test plan included tests for individual components, as shown in Figure 7.

It also proposed multiple scenarios for the full closed-loop simulation, shown in Figure 8.

This matters because AI-assisted engineering should not stop at artifact generation. For Model-Based Design, engineering review depends on connecting design intent to executable models, verification activities, and reviewable results. A workflow that helps generate tests alongside the model makes it easier for engineers to evaluate whether the model behavior matches expectations and whether there is enough evidence to approve the result.

The tests were then implemented in Simulink Test Manager, and the results are shown in Figure 9.

This is the difference between using AI to generate engineering content and using AI within an engineering workflow. The model, parameters, assumptions, and tests remain connected. Engineers still review the artifacts and remain responsible for the result, but the agent helps carry more of the repetitive work needed to move from intent to implementation and validation.

Why this matters

This example is not about generating a disk-brake thermal model.  It illustrates a broader issue in AI-assisted engineering: without structure, engineering intent can be lost even when models or code execute correctly. AI agents can accelerate model creation, but speed alone does not ensure that the resulting model reflects the intended system behavior or can be reviewed, validated, and maintained over time.

What made this workflow effective was not the ability to generate artifacts, but the way engineering intent was made explicit early and carried forward through planning, model construction, parameter definition, and testing. That continuity created clear review points before assumptions became embedded in executable models, reducing the risk that ambiguity would propagate unnoticed.

That matters most in safety- and certification-driven environments, where teams need more than a working result. They need evidence they can inspect, test, and use to support engineering decisions and sign off. But the same principle applies well beyond regulated domains. Any team building complex engineered systems depends on traceability, reviewability, and shared understanding to support collaboration and long‑term reuse. This is supported by tools like Simulink Agentic Toolkit, which gives AI-coding agents Simulink-specific context and workflow guidance. That grounding helps agents operate within the engineering process rather than relying on their general language-model knowledge alone.

Workflows that give AI agents access to engineering context and structure help reduce the hidden friction between what an AI agent can produce and what engineers need to trust, approve, and stand behind the result.

The post The hidden friction in AI-assisted Engineering appeared first on Microcontroller Tips.

A typical computational and control architecture for humanoid robots is hierarchical, designed to manage high-degree-of-freedom (DoF) mechanical structures while ensuring real-time stability and intelligent decision-making.

The computational and control architecture of humanoid robots are typically divided into three major layers: the AI section, the motion control system, and the body (Figure 1).

• The AI system, also called the ‘brain’, handles high-level processing and decision making, enabling task decomposition, task management, understanding the local environment, navigation, inference, learning, and interactions with people.
• The motion control system, the cerebellum, takes information and requirements from the AI system and determines the route to travel, motions to coordinate, balance, and kinematics, like walking.
• The body is responsible for task-specific actions and includes the vision and other sensors like IMUs and tactile feedback, and actuators with fast real-time control loops.

Chips and levels

The AI system processes massive amounts of data from vision and tactile sensors using sensor fusion to understand the environment and make decisions. Chips used here include graphics processing units (GPUs), neural processing units (NPUs), tensor processing units (TPUs), specialized AI accelerators, and high-performance SoCs.

In a humanoid robot, the cerebellum typically includes central processing units (CPUs), more SoCs, application-specific ICs (ASICs), and field programmable gate arrays (FPGAs) to manage real-time physical balance, smoothing joint movements, and adapting the robot’s stance on the fly without needing complex, high-level commands.

The execution layer in the body handles hard real-time safety, motor control loops, and direct sensor inputs at the joint level using microcontroller units (MCUs), ASICs, and a variety of driver ICs.

A humanoid robot can have dozens of joints for walking and grasping objects. Simple applications can use proportional motion algorithms where each joint can be controlled independently by using a simple control system. In more demanding applications, the coupled dynamic forces of the various joints are significant, nonlinear, and complex, demanding more computationally intensive control algorithms.

Basics of humanoid walking

Walking is a complex problem for humanoids. The most agile and human-like humanoids generally use 12 to 14 DoFs (6 or 7 per leg, for example, 3 hip, 1 knee, and 2 ankle) to allow for 3D mobility, complex movements, and balancing.

A simplified approach to humanoid walking treats the torso and arms as the upper-body, while the waist and legs are treated as the lower-body (Figure 2). This control system considers the entire upper body to be a large, rigid structure. Controlling the center of mass (CoM, or center of gravity) of the upper-body is key. The CoM is the single theoretical point where the mass is perfectly balanced.

Manipulator controls

Advanced humanoid manipulator controls require 6 DoF to reach any position and orientation in a workspace. A simpler 5 DoF configuration can be effective for tasks like welding or pick-and-place, where rotational movement about one axis is unnecessary.

• Waist provides base rotation left and right around a vertical axis.
• Shoulder moves the robot’s arm up and down, or forward and backward, in a vertical plane.
• Elbow bends and extends the arm, changing the reach of the manipulator.
• Wrist yaw allows the end-effector, or ‘hand’, to tilt up and down or pivot side-to-side for proper alignment.
• Wrist roll rotates the end-effector clockwise or counterclockwise along the axis of the forearm.

A typical manipulator control architecture, a master control is responsible for sending ‘set point’ information to each of the joint controllers. The joint controllers use the set point information to command the joint actuator to move the joint at the proper speed to the required position (Figure 3).

Summary

The computational and control architecture for humanoids is a layered structure designed to optimize efficiency and support real-time performance. A variety of digital, analog, and mixed-signal ICs, including GPUs, NPUs, TPUs, CPUs, motor drivers, ASICs, and so on, are used in the various levels of the computing architecture. Software tools range from the ROS and AI algorithms to sophisticated motion control software for real-time control of rapid movements.

References

A Multi-modal Architecture for Human Robot Communication, Stanford University
Beyond Wheels: Designing and Building a Walking/Bipedal Robot, KEYi Technology
Computational Options for Robotics, Distelec
Experimental Investigations into Using Motion Capture State Feedback for Real-Time Control of a Humanoid Robot, MDPI sensors
Experimental Validation of the Essential Model for a Complete Walking Gait with the NAO Robot, MDPI robotics
Humanoid robotics – E/E architecture, software and safety, FEV.io
Humanoid Robotics: Tackling Diverse Challenges with Modular Architecture, Advantech
Humanoid robots 101, BofA Institute of Global Research
Mathematical Modeling and Control Architecture of the Autonomous Lower Body of a Humanoid Robot, IIETA Mathematical Modelling of Engineering Problems
Next-Generation Whole-Body Control System of Humanoid Robots,arXiv
Software Architecture and Development for Controlling a Hubo Humanoid Robot, Purdue University
Walking control of humanoid robots based on improved footstep planner and whole-body coordination controller, Frontiers in Neurorobotics
What is the Best Programming Language for Robotics?, RobotIQ

Related EEWorld Online content

What kinematic equations are important for industrial robots?
How does the Zenoh protocol enhance edge device operation?
What are the applications of physical artificial intelligence?
The difference between physical AI and machine learning in power electronics
What is an AI governor and how does it relate to physical AI?

The post Computational and control architectures for humanoid robots appeared first on Microcontroller Tips.

Implementing robust sensor security is essential in connected systems. Compromised sensors can feed corrupt, inaccurate data directly into operational systems, leading to devastating real-world failures, catastrophic physical damage, safety concerns, and compromised decision-making. 

The increasing number of sensors in modern systems and the diversity of sensor types across applications like machine learning (ML) and automation present an expanding attack surface that can be invaded by bad actors.

Sensors are used in a variety of critical systems, from the electric grid to autonomous vehicles and pacemakers. Corrupted data can create life-threatening conditions. Corrupted data can also result in an AI application that makes incorrect predictions, resulting in unsafe actions. Adding to the challenges, sensors are often resource-constrained devices, making it difficult to integrate significant levels of security directly into the sensor.

The growing complexity of sensor networks further expands the attack surface, making implementing sensor security complex as well as critical. That necessitates implementing a defense-in-depth approach that embraces hardware, network, and software layers (Figure 1).

Strategies for sensor security

Hardware considerations for sensor security include tamper detection using physical switches, accelerometers, or other tools to monitor for unauthorized physical access. Unused ports should be physically sealed and secure boot implemented.

Network isolation can be important, including the use of virtual LANs to limit outbound sensor communication and block all unauthorized inbound connections. Use of a zero-trust architecture to verify all communication provides an additional level of security.

A well-regulated and controlled patch management process for the delivery of encrypted firmware updates is essential. ML tools can be used to identify anomalous sensor data that may indicate a sensor that’s been physically compromised or subjected to environmental manipulation.

Holistic approach

Strategies for sensor security must extend beyond the edges of traditional networking. Modern systems no longer include a so-called ‘air gap’ without wired or wireless connections that isolates individual systems from the rest of the operation. Today, most systems are designed to allow various types of external connectivity, adding dimensions of concern to the attack surface (Figure 2).

• Remote virtual private networks (VPNs) used for remote and global connectivity can be hacked.
• Manufacturing execution systems (MES) link high-level business planning systems (like enterprise resource planning, ERP) and the physical production floor.
• Engineering laptops and USB drives are often used to update systems and backup configuration data.

Wired vs. wireless

There are fundamental differences in attack surfaces and attack vectors between wired and wireless sensor implementations. Wireless connections cannot be disabled by simply cutting a wire. Wireless sensors can be targets for signal interception or manipulation.

Wired sensor networks are less flexible than wireless implementations and are vulnerable to communication or power cables being severed. Insertion of a resistor at the sensor end of a connection can allow the control panel to detect if a wire has been cut, or if a sensor has been tampered with. Wired connections can’t be easily intercepted and are relatively immune to hacking, jamming, and electromagnetic interference.  

OT vs IT

Finally, there’s a tension between the security demands of operational technology (OT) on the factory floor and information technology (IT) in businesses. For example, OT systems prize stability and infrequent changes while IT systems require more frequent updates to ensure maximum performance.

The intersection between IT and OT systems must be tightly managed. A strictly IT-related event is not generally life-threatening. An OT-related event can compromise safety. OT concerns extend to supply chain issues and ensuring that new sensors or other assets and maintenance or calibration tools don’t introduce security risks (Figure 3).

Summary

Implementation of sensor security in connected systems is as complex as it is important. There are multiple types of sensors, heterogeneous IoT architectures including wired and wireless devices, and application requirements to consider, plus the intersection of IT and OT systems to manage. External vulnerabilities from new equipment and calibration services can exacerbate the internal networking challenges.

References

A step-by-step guide to achieving fast, secure IoT connectivity and device lifecycle management, Crypto Quantique
Combining Edge Computing-Assisted Internet of Things Security with Artificial Intelligence: Applications, Challenges, and Opportunities, MDPI applied sciences
Enhancing Cyber Security Through Machine Learning-Based Anomaly Detection, International Journal of Engineering Research & Technology
IoT Security: Essential Strategies to Protect Connected Devices, Paessler
OT Cybersecurity: The Guide to Securing Industrial Systems, TXOne Networks
Secure OTA Boot Chains and Firmware Verification: Building Trust in Connected Devices, Promwad
Securing All Your Shiny New Connected Devices, NJCCIC
Securing Connected Devices: Enhancing IoT Security in Manufacturing, Orlan Tech
Security Considerations for Field Equipment in Industrial Systems, Industrial Cyber
Security for Industrial Control Systems (ICS), Splunk
Sensors Cybersecurity, MDPI sensors
What Is ICS Security?, Palo Alto Networks

Related EEWorld Online content

How does the Machinery Regulation (EU) 2023/1230 affect designs?
What is an AI governor and how does it relate to physical AI?
How will the Cyber Resilience Act impact embedded developers?
How does the Zenoh protocol enhance edge device operation?
OpenClaw is open-source edge AI for (almost) every application

The post How to implement sensor security in connected systems appeared first on Microcontroller Tips.