From requirements to runtime monitoring, robotics software must remain understandable, verifiable and maintainable
Software engineering for robotics does not end when functioning code has been produced. A robotic system must perceive its environment, make decisions, control physical components and respond to situations that cannot always be predicted during development. Its software may combine sensor processing, planning, control, communication and user interaction, often across different platforms and engineering frameworks.
Generative AI could support many of these activities. It can help engineers analyse requirements, propose system designs, produce code, generate tests or interpret runtime information. However, introducing generative AI does not remove the need for established engineering discipline. When software controls a physical system, generated outputs must remain traceable, reviewable and connected to evidence about their behaviour.
This is why ASTIR addresses AI-supported robotics engineering across the complete software lifecycle rather than treating code generation as an isolated task.
Robotics software operates in the physical world
A defect in conventional software may produce an incorrect result or interrupt a digital service. A defect in robotics software can also cause unintended movement, interrupt an industrial process or affect the interaction between a robot and the people around it.
Robotic systems must operate under conditions that are difficult to reproduce completely during development. Sensors provide incomplete or noisy information. Hardware components have physical limits. Communication can be delayed. People and objects move through the operating environment. The same software may behave differently when the robot, its configuration or its surroundings change.
Engineers must therefore consider more than whether a piece of code compiles or passes a set of unit tests. They must also ask:
Under which operating conditions is the software expected to work?
Which assumptions does it make about the robot and its environment?
How does a software change affect system behaviour?
Which tests provide evidence that requirements are satisfied?
How can unexpected behaviour be detected after deployment?
When must a human engineer review or approve an AI-generated result?
These questions extend across requirements engineering, system design, implementation, testing, deployment and maintenance.
A change in one phase can affect the entire system
The phases of the robotics software lifecycle cannot be managed independently.
Consider a manufacturing robot that must reduce its speed when a person enters a defined area. A change to the required separation distance may initially appear to be a requirements update. In practice, it could also affect the system architecture, sensor configuration, controller logic, safety-related interfaces, test scenarios and runtime monitoring rules.
If these relationships are not maintained, the development artefacts can diverge. The requirement may be updated while the corresponding tests continue to reflect an earlier version. Code may be modified without documenting which system assumption has changed. Runtime data may reveal recurring behaviour that never reaches the teams responsible for requirements or design.
Traceability helps engineers understand these dependencies. It connects a requirement to the architecture elements that realise it, the code that implements it, the tests that examine it and the operational evidence collected after deployment.
This becomes especially important when generative AI contributes to engineering work. An output may appear plausible while overlooking a constraint recorded elsewhere in the project. Engineers need to know which information was used, what was generated, how the result was checked and which artefacts could be affected by accepting it.
Where generative AI could support engineers
Generative AI offers opportunities throughout the robotics software lifecycle.
During requirements engineering, it could help organise stakeholder needs, identify ambiguous statements or suggest links between requirements and existing engineering artefacts. In system design, it could support the comparison of architectural options or help transform information between modelling formats.
During implementation, generative AI could propose source code, configuration files or documentation. It could also assist with adapting existing software to a new platform or component. In testing, it could derive test cases from requirements, identify missing coverage or help analyse failures. After deployment, it could support the interpretation of logs and runtime observations, helping engineers identify anomalies or possible maintenance needs.
These forms of assistance have different risks and evidence requirements. Summarising a log file is not equivalent to modifying a robot controller. Generating a test proposal is not the same as deciding that a system is safe to deploy. The degree of automation and required human review must therefore reflect the consequence of the engineering decision.
The aim is not to replace an engineering process with a direct prompt-to-robot shortcut. Generative AI should operate within structured workflows in which intermediate results can be inspected, validated and, where necessary, rejected.
From a sequence to a connected lifecycle
A useful representation of the robotics software lifecycle includes six closely connected areas:
Requirements: defining intended behaviour, operational conditions, constraints and quality expectations.
System design: allocating responsibilities to software and hardware components and specifying their interfaces.
Implementation: developing, generating, integrating and documenting software components.
Testing and validation: examining individual components and integrated behaviour against requirements and realistic scenarios.
Deployment: configuring and transferring verified software to the target robotic system.
Runtime monitoring and maintenance: observing behaviour, detecting anomalies and managing changes after deployment.
This lifecycle is not a one-way sequence. Runtime observations can expose assumptions that were incomplete during design. Test results can require changes to requirements. A new hardware component may affect architecture, implementation and deployment. Maintenance therefore feeds information back into earlier engineering activities.
A lifecycle-based approach makes these feedback paths explicit.
The ASTIR approach
ASTIR is developing an AI-augmented engineering workbench for intelligent robotics software. The workbench is intended to support activities from requirements engineering through system maintenance while integrating with established engineering practices.
A central concern is the connection between engineering artefacts. Requirements, architectural models, source code, tests, security-related information and runtime observations should not become isolated collections of data. Their relationships need to remain available to the engineers assessing a proposed change or generated result.
This approach is intended to support:
inspectable intermediate artefacts rather than opaque outputs;
traceability between lifecycle phases;
verification of generated or modified engineering artefacts;
integration with existing development practices;
human oversight of consequential decisions; and
feedback from deployed systems into maintenance and further development.
ASTIR will examine its methods and tools through use cases in manufacturing robotics, service robotics and drones. These domains provide different operating environments and engineering constraints, allowing the project to investigate where AI support is useful and where stronger controls or expert intervention are required.
Engineering assistance must remain accountable
The value of generative AI in robotics engineering will not be determined only by how much code it can produce. More important questions concern whether its outputs are correct in context, whether their origin and consequences can be understood, and whether engineers can obtain sufficient evidence before those outputs affect a deployed system.
A lifecycle-based approach provides the structure needed to ask these questions consistently. It connects AI assistance with requirements, system knowledge, verification activities and operational feedback.
ASTIR is investigating how these connections can help engineers use generative AI productively while retaining control over the development and maintenance of intelligent robotic systems.
Follow the ASTIR website and LinkedIn channel for upcoming articles examining individual lifecycle challenges, including requirements analysis, system design, implementation, testing, security, runtime monitoring and maintenance.