I don’t like change. I know I’m starting to sound like an old codger, but that’s OK because I am an old codger (I know the secret handshake and I have the ceremonial undergarments T-Shirt to prove it). For example, I remember going to the Design Automation Conference (DAC) year after year throughout the 1980s. The same companies were there each time, but it seemed like everyone I knew had moved from one company to another between conferences. It was very confusing. It made my head hurt.
Since then, the same thing has been occurring with the companies themselves. All I have to do is turn my attention for a moment. When I turn back, I find the company I just talked to has either acquired another company or been acquired by another. It’s very confusing. It makes my head hurt. So at least that’s one thing that hasn’t changed, although these days the pace of mergers and acquisitions seems to have shifted from “occasional surprise” to “blink and you’ll miss it.”
For example, I met the guys and gals from LDRA and wrote about them back in 2023 (see We’re Going Back to the Moon (and LDRA is Helping to Get Us There)!). As you can see, I wrote this in the halcyon days before the punctuation police forbade me from terminating my column titles with exclamation marks.
Well, blow me down! I was just chatting with Christoph Herzog, who is Co-CEO and CTO at TASKING, and it turns out that LDRA was acquired by TASKING just last year (that’s 2025 as I pen these words).
Actually, there’s still more to this story. As we see in the timeline below, TASKING was formed in 1977 (if you’re having trouble reading the small writing, I just uploaded a full- size copy of this image for your reading pleasure—you’re welcome).
TASKING timeline at a glance (Source: TASKING)
TASKING started as a software consulting company in 1977 and moved into compiler technology during the 1980s. From its inception until roughly 2022, TASKING was best known in the embedded-systems world primarily for its highly optimizing C/C++ compilers and development toolchains for microcontrollers, particularly those used in automotive and other safety-critical applications. Over the decades, TASKING has built a reputation for deep, architecture-specific optimization and tight integration with popular automotive processors such as Infineon’s TriCore and AURIX families, as well as other embedded architectures used in industrial and transportation systems.
Now let’s bring iSYSTEM into the picture. Founded in 1986 in Slovenia, iSYSTEM made its name in the embedded world as a supplier of professional hardware debugging and trace tools. For many embedded developers—especially those working on complex automotive and industrial systems—the company’s BlueBox debug probes and its winIDEA development environment became familiar companions during long days (and even longer nights) of firmware development. Prior to its acquisition by TASKING in 2022, iSYSTEM was widely respected for its high-end debugging, tracing, and timing- analysis capabilities, particularly for multicore and safety critical embedded targets.
And then there’s LDRA. Founded in 1975 in the UK, LDRA carved out a very different—but highly complementary—niche in the embedded software ecosystem. Instead of compilers or hardware debug tools, LDRA became famous for its software verification, static analysis, and test tools, especially for safety-critical systems. Over the years, LDRA’s tool suite became widely used in industries such as aerospace, automotive, rail, and medical devices to help developers meet rigorous standards like DO-178C, ISO 26262, IEC 61508, and others. By the time TASKING acquired the company in 2025, LDRA had spent decades helping engineers prove—not just hope—that their embedded software behaved exactly as intended.
As an interesting nugget of knowledge and a tidbit of trivia, Christoph noted that, as of 2026, TASKING, iSYSTEM, and LDRA collectively have 140 years of corporate experience under their belts. Of course, that made the engineer in me wonder how many years of engineering experience they have. To work this out, we would need to know when each engineer joined and how long they had been with the company (some will have moved on to other companies, retired, or… well, we don’t need to go there). You can only imagine my surprise to discover that Christoph had wondered the very same thing, so he went through the records and came up with 1,213 years of cumulative engineering experience!
All of which brings us to the interesting part. When you step back and look at TASKING, iSYSTEM, and LDRA together, something very compelling emerges. Historically, each of these companies occupied a different stage of the embedded software lifecycle. TASKING focused on compiling code efficiently for specific processor architectures. iSYSTEM specialized in debugging and runtime analysis of that code once it was running on the target hardware. LDRA concentrated on verification, testing, and proving that the software met the stringent requirements imposed by safety standards. Individually, each company was respected in its own domain. Together, they form something much larger: an end-to-end embedded software development toolchain spanning compilation, debugging, and testing.
In practical terms, this means developers can now move through the entire lifecycle—from source code through execution and verification—without leaving a single tool ecosystem. Source code can be analyzed for compliance with standards such as MISRA-C and CERT-C, compiled with highly optimizing compilers, flashed to the target, debugged and traced on the running hardware, and then fed directly into verification and testing workflows. Data generated during debugging and runtime analysis can flow straight into the testing and validation environment, creating a continuous feedback loop between compilation, execution, and verification. The result is a development process that is both faster and easier to certify for safety-critical applications.
This integrated approach represents a significant evolution toward what Christoph describes as “TASKING 3.0”, as illustrated below. Historically, the original TASKING tools were often associated with a single architecture—most famously Infineon’s TriCore family. Today, the company’s strategy is deliberately architecture-agnostic. The toolchain now supports a growing range of processor families, including TriCore, Arm, RISC-V, and Renesas RH850, allowing development teams to move between hardware platforms without abandoning their established tools or workflows.
From TASKING to TASKING 3.0 (Source: TASKING)
Equally important is the transition from individual tools toward a tightly integrated development environment. In the past, developers might assemble their own toolchain from different vendors: a compiler from one company, a debugger from another, and verification tools from yet another. TASKING’s current vision is to bring these capabilities together into a unified workflow. Compilers from TASKING, the winIDEA debug environment and BlueBox trace hardware from iSYSTEM, and the LDRA verification suite now operate as parts of a coordinated pipeline that spans the entire development lifecycle.
Bringing the tools together (Source: TASKING)
Another notable aspect of this approach is flexibility. Developers are not forced into a single IDE or working style. The toolchain can integrate with widely used development environments such as Eclipse, JetBrains tools, Visual Studio Code, or vendor-specific IDEs from silicon partners, including Infineon, NXP, Renesas, and Synopsys. The same workflows can operate in both virtual and physical environments, allowing engineers to begin development on simulated hardware models and transition seamlessly to real silicon once it becomes available.
Automation also plays a large role in this strategy. The entire toolchain can be driven through command-line interfaces and Python scripting, enabling headless operation in modern continuous integration/continuous development (CI/CD) pipelines. This allows developers to automate complex tasks such as building, flashing, testing, and profiling software across multiple hardware targets. It also means large development teams can integrate the tools directly into modern DevOps workflows.
Perhaps the most intriguing development, however, is the introduction of AI-driven workflows into the toolchain. Traditionally, developers manually experimented with compiler optimization settings, debugging strategies, and testing configurations. With TASKING’s new AI-enabled approach, large language models can orchestrate the entire development pipeline. An AI agent can iteratively adjust compiler flags, rebuild the code, deploy it to the target hardware, run benchmarks, capture trace data, analyze performance, and repeat the process thousands of times to discover optimal configurations.
In other words, the AI is not writing the embedded software itself; rather, it’s acting as a sophisticated automation layer that explores design spaces far more thoroughly than most engineers could realistically attempt by hand. Developers remain firmly “in the loop,” evaluating trade-offs between performance, memory usage, test coverage, and compliance with coding standards. But the tedious trial-and-error work can now be automated and accelerated.
The importance of this becomes particularly clear in modern multicore systems. As processors grow more complex, subtle interactions between cores can affect worst-case execution time and system determinism. The integrated TASKING toolchain combines compiler analysis, hardware tracing, and LDRA verification tools to measure and mitigate these timing interactions—an increasingly important requirement for systems that must meet strict safety standards such as ISO 26262 and DO-178C.
Another notable shift involves the markets TASKING serves. Historically, the company’s tools were most closely associated with the automotive sector, where its compilers became widely used for microcontrollers that power electronic control units (ECUs) in vehicles. Automotive remains an important focus today, but the scope has expanded significantly. With the addition of iSYSTEM’s debugging technology and LDRA’s verification and testing capabilities, TASKING now positions its integrated toolchain for a broader set of safety- and security-critical domains, including aerospace and defense, industrial automation, and robotics.
TASKING’s broader market presence (Source: TASKING)
Taken together, these developments mark a significant shift in TASKING’s role within the embedded ecosystem. What began nearly fifty years ago as a company known primarily for its optimizing compilers has evolved into something much broader: a provider of a fully integrated development, debugging, and verification environment for safety- and security-critical embedded software.
And this transformation is arriving at exactly the right moment. Embedded systems are becoming more complex, more interconnected, and more software-defined than ever before. Vehicles are turning into rolling data centers. Robots are moving out of research labs and into factories and warehouses. Aerospace systems are becoming increasingly autonomous. In all these domains, software must not only perform but also be provably safe, secure, and certifiable.
That’s where the combination of TASKING, iSYSTEM, and LDRA starts to look particularly interesting. By bringing together compilation, debugging, analysis, verification, automation, and now AI-assisted workflows into a single ecosystem, TASKING is positioning itself at the center of how safety-critical embedded software will be developed in the years ahead. Speaking as a grizzled old embedded engineer who doesn’t usually like change, I have to admit that this is actually a pretty exciting one.
