TACTIC

Welcome to a quick look at Tactic. Traceability, automation, continuous testing, and code integration. Before we dive in, let's first discuss the architecture of Tactic. Tactic builds on two open schemas, AUTOSAR and REKIF, that describe how software components are structured and what requirements they must satisfy. Source data comes from one of two places: file based input like ARXML or REQF files or a live connection to a SystemWeaver server. Both schemas and source data feed into Pydantic model sets. The Pydantic classes are generated once from the schemas, so every field of incoming data is validated against the standard before it reaches your project. The models cover the core design concepts, software components, service interfaces and requirements. Once validated, the data is transformed into YAML. This transformation is configurable per project. You decide which fields and views matter for your team. These YAML files live in a hidden tactic meta folder inside your code base. The folder holds three things: the code contract, the requirements, and a traceability database that your team builds up over time. A shared core logic layer reads those YAML files. It powers two surfaces: a language server that any modern IDE can talk to, and a CLI tool that runs anywhere, including in your CICD pipeline. And here's the key. The core logic itself stays language agnostic. All language specific work happens through pluggable adapters. C, C plus plus and Python. One model, one core, many platforms. For this demo, we'll focus on OTOZAR Classic. Let me hand it over to my colleague to walk you through tactic in action. Thanks. Let's start with a standard c file in Versus Code. Right now, there's no underlying model data. If we hover over a runnable or an RTE API, we don't get any AUTOSAR context and we lack intelligent code completion. Let's switch over to SystemWeaver and look at our engine control module. This is our complete architectural source of truth. Here, we can visually explore the architecture to understand the complex interactions between application software components and composition SWCs. The inbox contains all design requirements. Here we can see specific details, like the requirement description and its ID. These design requirements from the inbox are mapped directly to their respective NSWCs. Looking closer, we can see send and receive ports, complete with data types, compu methods, and physical units. The internal behavior also defines the runnables, interrunnable variables and services. Finally, the composition SWCs contain multiple application SWCs connected together via these ports. It's a rich, powerful model. But having to leave your IDE to find this information completely breaks your development flow. We will copy the handle of the design area item and later use it to get data into the Tactic extension for Versus Code. Currently, the contents folder is empty and the Tactic extensions contract requirements, and coverage sections are empty as well. Let's bring our ECM model into the IDE. First, we will set up the Systemweaver server host and port and paste the handle we copied earlier. Now we generate the metadata. This pulls data for all software components and requirements into the IDE. And the three sections in the tactic extension sidebar fill in. Similarly, the contents folder now has a contract dot YAML file for all SWC details, and the requirements folder has the requirements in a separate YAML file. A traces dot YAML file maintains the traceability between requirements and the runnables or RTE APIs they're linked to. Let's head over to the tactic extension. The sidebar has three core sections, contract, requirements, and coverage. Each one is built around the same idea, surface the AUTOSAR model right next to your code. Start with the contract section. This is your project's component map. Every application software component in the project is listed at the top level, alphabetically, including any nested inside a composition SWC. Each SWC expands to show its runnables, and each runnable expands to show its RTE APIs, reads, writes, parameter, accesses, server calls. With one click, you can navigate from a top level component down to a specific data right or send point without ever leaving the editor. Next, the requirements section. Instead of a flat list, requirements are grouped by the SWC they belong to. Exactly the structure that exists in System Weaver mirrored in your editor. So if you're working on the throttle controller, the requirements that govern it are right there, one expand away. And the coverage section is the audit view. For each SWC, it shows runnable, API, and requirement coverage totals, then lists the untraced runnables, APIs, and requirements by name. A coverage issue section services any broken or stale traces. Now when we hover over any runnable, we can see its details, like the name and traced requirements. When we hover over an RTE API, it lists details like the name, API type, interface, port, data type, and requirement trace. If a runnable does not exist in the model, we get no details when hovering over it. When adding an RTE API inside a runnable function, the Tactic extension auto completes only those APIs that exist in the current runnable function. In the contract section under the throttle controller SWC, the recalc throttle runnable has three APIs, the exact three the tactic extension just suggested. Move outside that runnable and we see the full project's APIs instead. To add a requirement trace, place the cursor on either a runnable name or an RTE API call and run the add trace to current symbol command. We start with the runnable itself, placing the cursor on recalc throttle, searching for and selecting the appropriate requirement, and the trace is saved immediately. Inside the coverage section under the throttle, controller SWC, the traced runnable count ticks up, and the untraced number drops, all without any manual refresh. We can do the same at the API level. Placing the cursor on an RTE API, we add a trace from that API to its corresponding requirement. The coverage section updates again. This time the API count moves up alongside the requirement count we already have, and the project level coverage shifts accordingly. Two traces, two visible coverage updates, all reflected live. Clicking any requirement in the requirements list reveals its full details. Description, handle and ID in a side panel. The traceability grid gives a project wide view of every trace your team has created, mapping runnables and APIs to their requirements. It also captures the version of each requirement at the moment the trace was made and compares it against the current version of the same requirement. If the requirement has changed in SystemWeaver since you traced to it, the grid flags the trace, So you know exactly which links and need a re review. If nothing has drifted, the grid shows the trace as traced correct. After deleting our requirement trace, that requirement no longer shows in the traceability grid and the coverage section is updated as well. Everything you've just seen in this c file works the same way in c plus plus Let me show you. Here's a c plus plus file from the same project. Hovering over a runnable shows its details, just like in C. Autocomplete suggestions work identically. This is what language adapters means in practice. The core logic doesn't know or care which language the file is in. The C plus plus adapter handles all the language specific parsing. The same applies whether you're working on AUTOSAR Adaptive, Eclipse S Core, or Android AutoCode. The key takeaway here is simple: Developers can work fully in their IDE without needing to open System Weaver. And because all of this is built on a shared core, the same coverage data is available outside the IDE. Run the command line tool on your project, and you get a coverage report for each software component, ready to feed a CICD pipeline, and the same coverage data appears in the terminal. Per SWC totals, untraced items, and any broken traces, ready to feed a CICD pipeline. With that, let me hand it back to my colleague for the recap. Stepping back to the full picture, TACTIC takes one source of design data, ARXML, RecuF or a live System Weaver server, and validates it through PyDantic against OpenAltazar and RecuF schemas. The validated data is transformed into YAML metadata that lives alongside your code, holding your code, contract, requirements and traceability database. A shared core logic reads that metadata and serves two surfaces: working through pluggable language adapters for c, c plus plus and Python. And this is where Tactics Reach really opens up. First, the language server, because the analysis runs through the language server protocol, the same protocol that powers Microsoft's modern editor tools, tactic slots into any IDE that speaks LSP, Versus Code, Visual Studio, CLion, and others. Your team doesn't have to standardize on a single editor to get the same design aware experience. Second, the CLI. The same trace, coverage and contract analysis you saw in the editor runs as a command line tool. Drop it into any CICD pipeline, Jenkins, GitLab CI, Azure pipelines, and the same checks that help a developer in their IDE now run automatically on every commit. Coverage gaps surface in pull request reviews, broken traces, fail builds. Traceability becomes part of your team's quality gate, not a manual audit at the end. And those adapters are what let Tactic reach across so many platforms. The C adapter handles software running on Autosar Classic, FreeRTOS, and Zephyr projects. The C plus plus adapter covers AutoStar Adaptive, Eclipse S Core, and Android Auto. And a Python adapter brings support for testing frameworks like PyTest and UnitTest. One model, one core, every platform, every editor your team uses, every pipeline your team runs. That's tactic.