Before a single line of production code can be written for critical projects, teams need a compliant, qualified, automated development environment in place, and building one from scratch takes years most programs don't have. This article breaks down the framework intive has developed and proven on automotive series programs: three layers of process, tooling, and automation that turn compliance from a bottleneck into a foundation, and the principles that keep it holding up under real scrutiny. It also shows how the same framework opens up to AI agents, while every rule, right, and record stays inside your own infrastructure.
When the requirements for a series product land on your desk, whether it is an automotive ECU, an industrial controller, a medical device, or an avionics module, the hard part usually isn't writing the code. It's having a development environment ready to write it in. A compliant, qualified, automated toolchain and the processes around it take years to build. Most teams don't have those years once a program has already started.
That gap between "we won the project" and "we can actually develop against it" is what intive has spent years learning to close.
We first solved this challenge within our own series production programs because we could not deliver without addressing it. The approach was developed and refined through automotive series development, where compliance requirements are among the most demanding in embedded software engineering.
The result is not a single off-the-shelf product, but a framework: a proven, repeatable approach for establishing a mature, audit-ready development environment for safety-critical embedded software. It is supported by engineering services that help organizations implement, adapt, and continuously improve the framework over time.
The framework, in three layers
Regardless of the domain or the specific tools involved, a development environment that can withstand external scrutiny depends on three layers working together.
1. Mature processes
Every activity from requirements to release is clearly defined, documented, and owned. Processes are continuously improved and designed to withstand external assessments, whether against Automotive SPICE or any other compliance framework required by your industry.
2. A qualified, harmonized toolchain
Requirements, architecture, modelling, coding, test, source control tools are carefully selected, qualified where required, and integrated into a seamless workflow, allowing work to move efficiently from one stage to the next without friction at every handoff.
3. Two kinds of pipeline automation
CI/CD pipelines handle the build itself: every commit triggers a build, test, and package cycle, so a releasable artifact is always available. Lifecycle automation handles everything else: the work outside the build that still has to happen but shouldn't be done by hand, such as generating code, calibration data, and release notes; reconciling a customer data delivery against the requirements baseline; and producing the traceability evidence an assessor will ask for.
Unlike CI/CD, it isn't triggered by commits – it runs on lifecycle events instead: a delivery arrives, a requirement changes, a defect ticket is raised, a release milestone lands.
What it looks like in practice
This wasn't designed on a whiteboard. It was developed over years of market research, prototyping, tool qualification, and hands-on rollout – resulting in a reference implementation that we proved end to end on automotive series programs, the most compliance-heavy work we do.
Our process automation follows one principle: every pipeline has its own trigger. Lifecycle automation generates and syncs artifacts in response to engineering events, while the CI/CD pipeline builds, tests and packages the software on every commit. The tables show the two pipelines at the core of our development flow: the SWC specification pipeline and the CI/CD pipeline.
The second pipeline covers what happens after the code reaches the repository: review, build, test and packaging (Figure 3).
The same event-driven approach is used across the rest of the lifecycle. Some examples:
- New ARXML from the customer. When a customer delivers a new ARXML file (the machine-readable interface definition), an ARXML parser extracts the application, port and interface specifications and syncs them to Codebeamer.
- New or updated customer ticket. A customer ticket sync keeps Codebeamer, our requirements baseline, aligned with customer tickets.
- Release milestone. Reaching a release milestone triggers two generated artifacts:
- An A2L file, built from the annotated comments in the sources, for calibration tools.
- Release notes, produced as a PDF from AsciiDoc, covering known bugs, test summary, configuration and memory usage.
Closing note
In this implementation the requirements baseline is Codebeamer. It can be swapped for Polarion, DOORS or Jama; the triggers and the pipelines stay the same.
Alongside CI/CD and tool integration, lifecycle automation is the element that most often makes the difference. It does the work around the build, and it is where the mature processes stop being documents and start running: an activity on the process map becomes a pipeline that fires when its triggering event happens.
For example, consider the following pipeline.
- The customer’s machine-readable interface definition (ARXML) is parsed to extract application, port, and interface specifications. These are then synchronized with the requirements baseline, while defect tickets are imported from the customer’s own tracking system.
- When the component specifications change, a single pipeline is triggered in two stages. First, the updated specifications are synchronized to the Git repository, together with a diff showing what has changed. Then, the corresponding software component code is generated automatically from the updated specifications.
- At each release milestone, the pipeline also generates the A2L calibration description – the file that allows calibration tools to locate and tune parameters on the target – along with the release notes.
- The team uses this baseline for development and implementation. A commit to GitLab then triggers the CI/CD pipeline, which builds, tests, and packages the software artifact. This ensures that a releasable build is available with every commit, rather than having to assemble and validate the release manually under deadline pressure.
Because these were automotive programs, the solution was measured against automotive standards: development to ASPICE Level 2 across the VDA scope and functional safety up to ASIL B in accordance with ISO 26262.
The same approach can be applied beyond automotive. While the industry may change, the core requirements remain similar: a SIL-rated industrial controller or an IEC 62304 Class B device still requires end-to-end traceability from requirements to tests, qualified tools, and reproducible builds.
What changes from one industry to another is the specific evidence required by the assessor, the level of tool qualification needed to meet the applicable safety standard, and the data formats used at the system boundaries. We scope these elements individually for each program, while the underlying three-layer architecture and the way these layers work together remain consistent.
Opening the framework to AI agents
A framework built this way is ready for agentic engineering. Requirements, design, code, tests and builds are already linked, and every process is already defined. An AI agent needs exactly that context to do useful work, and a regulated program needs exactly that control before it lets an agent in.
The connection runs through the Model Context Protocol (MCP), the open standard AI assistants and agents use to read data from other systems and trigger actions in them. Each part of the lifecycle gets its own MCP server: requirements, architecture, source control, testing, build, and the process layer that already coordinates the automation. A single gateway sits in front of them. The tools themselves stay as they are, and any MCP-capable client can use them, from an assistant in the developer’s IDE to an agent built for one program.
Many tools in a typical embedded toolchain already ship their own MCP servers. For the rest, and for our own lifecycle automation, we add thin ones. Syncing a new ARXML delivery, generating release notes or analyzing memory and stack usage then become actions an agent can call, with the same triggers and checks as before.
The real value shows when an agent works across component boundaries:
- Impact analysis. A change request arrives. The agent traces it through requirements, design, code and tests and lays out what it touches before anyone starts estimating.
- Release readiness. Before a milestone, the agent checks every quality gate, open defect and traceability gap and puts the result in one report for the people who make the gate decision.
Both use cases only read data. That is where we recommend starting: the value across the toolchain is visible right away, and nothing is written.
Inside your infrastructure, under your rules
For regulated programs, AI-ready means controllable. The gateway is the only way in, and it enforces the rules the framework already has:
- Agents act on behalf of a named user, through your identity provider, and inherit exactly that user’s rights.
- Tools are enabled per role and per project, with write access separate from read access.
- Changes to baselines, releases and quality gates always need human confirmation. Agents prepare drafts. People decide.
- Every tool call is logged with user, agent, model, input and result, so the log can serve as assessment evidence.
- AI-generated requirements, tests and code are marked as such and go through the regular reviews.
- You choose the model: a cloud service, an EU region, or a private model on premises. Your data stays within the boundaries you set.
- Content from requirements, code or tickets is treated as data, never as an instruction to the agent.
Agents that produce or check work products are classified like any other tool under ISO 26262. The pragmatic path is to run their output through the same qualified verification tools and reviews as manually created work. This is what AI-native, human-led means in embedded engineering: agents take on the legwork, and people keep the accountability.
The principles that hold it together
Set aside the specific tool names, and it comes down to the same handful of principles – these are what separate a toolchain that holds up over time from one that quietly rots:
- One source of truth, everything else derived. Requirements, interfaces, and specifications live in exactly one place, and nothing downstream re-types what already exists there: code comes out of the specifications, release notes out of the defect records and test results. Manual transcription is the source of both the errors and the version skew.
- Every process has an owner and a number. A process map with clearly defined owners, inputs and outputs, supported by a RACI matrix and measurable KPIs. Process documentation without clear ownership quickly becomes outdated; when someone is accountable for the process, it can be continuously monitored, maintained, and improved.
- Nothing is relied on before it is qualified. Compilers, test tools, and code generators are qualified for the safety level at which they'll actually be used – and this happens ahead of the program that depends on them, not scrambled together during the assessment that later questions them.
- Agents follow the same rules as people. They go through the same process and permission layer as the rest of the automation, never through a side door into individual tools. An agent’s output stays a draft until a person accepts it.
Automation is where most of the leverage sits, and where most of the damage gets done, so it earns its own rules:
- Automation follows the process. Scripts automate steps the process has already defined, and the data flow between tools is deliberately designed rather than improvised. Bolting automation onto an undefined process just makes the mess arrive faster.
- The trigger is the event that caused the work. A customer delivery, a specification change, a defect ticket, a commit, a milestone: each should fire the work it's tied to, the moment it happens. Nothing should depend on someone remembering it, and nothing should run on a nightly schedule when it should have run on the triggering event instead. The gap between "it changed" and "we noticed" is where integration problems take root.
- Automation is treated as product code. Scripts are versioned, reviewed, and qualified like the software they act on. A generator that produces safety-relevant code is itself safety-relevant. Automation living in someone's home directory is a single point of failure with a notice period.
- Builds are reproducible by default. Any build can be reconstructed from the commit that produced it, using the same qualified toolchain, yielding the same result. "It worked on the integration machine" doesn't count as evidence.
- Evidence emerges as a by-product of doing the work. Test summaries, memory figures, release notes, and traceability data fall out naturally from the pipelines that build and test the software. No one should be assembling an evidence package the week before an assessment.
These principles define what a robust development environment requires. Turning them into an operational setup, however, demands dedicated engineering expertise, tool knowledge, and implementation experience.
Where we come in
Setting up an environment like this – or bringing an existing one up to the required standard – is an engineering effort in its own right. That is the work intive does together with you:
- Assess and design: We assess your processes and tool landscape against your goals, customer requirements, and applicable standards, such as ASPICE, ISO 26262, IEC 61508, IEC 62304, or their equivalents in your industry.
- Implement and integrate: We qualify the necessary tools, build the infrastructure, set up the CI/CD pipelines, and integrate them with your existing toolchain. The environment is designed to fit your existing way of working.
- Automate: We automate manual, repetitive steps that slow teams down, using proven automation patterns and practices to accelerate delivery. And make it agent-ready: We connect your toolchain to AI agents through MCP, run the gateway on your infrastructure and identity provider, and start with read-only use cases before agents are allowed to write.
- Continuously improve: We evolve the framework over time, for example toward ASPICE Level 3 and higher safety integrity levels, while applying lessons learned from previous engagements.
The lifecycle automation is designed and built specifically for your program, with the scope tailored to your actual needs. You own the resulting solution and run it on tools that you license directly.
Across engagements, intive brings proven patterns, experience, and engineering expertise that help teams build and improve these environments efficiently.
Reliable, scalable and safe software depends on everything that has to be in place before development even starts. intive brings a framework proven under automotive’s compliance bar and adaptable to yours, along with the engineering expertise to build, adapt and continuously improve it, and to open it to AI agents on your terms. Your team can focus on the product, not the plumbing.
Planning a compliance-driven series program, improving your existing development environment, or exploring agentic engineering under ASPICE and ISO 26262? Contact us to discuss which elements of the Embedded Foundry can deliver the greatest value for your specific needs.
.png)
.png)
.png)
.png)