AS: AUTOSAR 4.4 basic software built by one author

One author, one AUTOSAR 4.4 tree, thirteen listed targets

AS describes itself as an open source implementation of automotive software based on AUTOSAR 4.4, covering BSW modules, PC tools and supporting libraries, developed independently by one author. That single sentence sets the expectations correctly. This is not a vendor consortium project with a roadmap board and a bench full of integrators; it is one engineer's public tree, and the platform list in the README is the honest measure of how far it has actually been taken.

The problem it addresses is real enough. Any engineer building CAN or LIN electronic control units hits the same wall: communication stacks, diagnostic handling and non-volatile memory management are large amounts of protocol code that every supplier charges for separately. AS offers those pieces as C source, plus the host-side tooling that makes them testable, under terms that allow study and evaluation without a purchase order.

The target audience is therefore narrower than the module count suggests. Researchers, engineers building bench tools, and teams prototyping an ECU outside a vehicle programme will find real value here. Teams shipping a road-going product face a different calculation, which the licence section covers later.

The platform table is the actual roadmap

The most useful part of the project page is a table of MCU and ECU platforms with two columns, Bootloader and Application. Thirteen entries appear, and they are not uniform.

The bootloader column is mostly CAN, with LIN for the Microchip SAMD21 and SAMDA1, CAN+LIN for the NXP MC9S12XEP100, and CAN plus DoIP in application for the Infineon AURIX TC3x7. The application column lists Com Stack, Diagnostic Stack and Memory Stack for many parts, but the TI CC27xx and the NXP MPC5634M entry drop the Memory Stack, and the AURIX line adds DoIP and SOME/IP-SD on top.

That unevenness is the point. It tells you where the work landed. The QEMU entry listing virt, versatilepb, x86 and STM32-P107 targets is the most useful line for a newcomer, because it means the CAN stack, diagnostic stack and memory stack can be exercised on a virtual machine with no board on the bench. The Infineon TC3x7 entry is the one to read if your interest is DoIP or service discovery. Everything else is a conventional CAN ECU profile. A documentation index names CanIf, CanTp, LinIf, Com, PduR, Dcm, Dem, Mirror, SecOC, E2E, SOME/IP-SD, DoIP, TLS, VDDS and XCP with Chinese and English pages for each.

Simulators over IP sockets and a Python API for tests

The host side is what makes the firmware testable, and it is where AS goes beyond a bare set of drivers.

Two simulators appear at the top of the tools list: CanBusSimulator, a CAN bus simulator over an IP socket, and LinBusSimulator for LIN. Both are network-facing, so a test rig can sit on one machine and the ECU under test on another. Alongside them, CanLib reaches real CAN hardware including Vector CanCaseXL, PeakCan and ZLGCAN adapters, while LinLib covers COM ports, USB2I2C and USB2SPI hardware. DevLib is described as an abstraction for reaching other kinds of automotive devices.

The protocol libraries sit in between. IsoTp implements the ISO 15765 transport layer over LIN and CAN FD, Loader is the library used by the bootloader, and DoIPClient talks to a DoIP server. VDDS is a virtio ring buffer and shared memory based DDS.

For test authors the entry point is AsPy, described as a Python interface exposing APIs for CAN, LIN and IsoTp so that test cases are easy to write. There is also a JSON Editor, a JSON schema and PyQt5 based configuration GUI, which implies configuration is expressed as JSON rather than through a proprietary toolchain format. That combination of simulated bus, Python bindings and a schema-driven editor is the part of AS most likely to shorten a test cycle.

asone and the Lua engine behind its scripts

asone is the GUI tool, and it comes in two flavours that behave differently in practice.

The project offers a Python version and a pure C++ version built on Qt, and the recommendation is explicit: the C++ version is preferred. Both cover Com, Dcm and FlashLoader work. What makes asone more than a viewer is that it embeds a Lua engine for UICom and UIDcm, so scripts can drive the communication and diagnostic flows instead of clicking through them.

The README separates the three tool roles that customers have used. UICom is the PC tool for CAN and LIN based signal communication, scriptable with Lua. UIDcm is the PC tool for CAN and LIN based UDS, where Lua scripts process request and response data and display the result. UIFBL is the flashloader and bootloader tool on the same bus.

Release history gives a sense of where the effort sits. The most recent tagged release is asone-qt-6.6.1-v0.1, described as a Qt 6.6.1 based C++ asone tool, published on 2024-01-14. Two earlier tags are prebuilt demos rather than releases of the core library: NetApp-0.0.1, a DoIP and SOME/IP-SD demo over lwip with a PCAPIF, and OSEKNM-0.0.1, an OSEK NM demo over a CAN simulator, both from 2021. The naming convention there says something useful: early work went into network management and service discovery demos.

Building a first target from the QEMU virtual CAN path

The project does not publish install commands on its main page, so treat the documentation index as the setup manual. The build environment guide exists in both languages at doc/EN/build-env-setup.md and doc/CN/build-env-setup.md, and the virtual bus guides sit next to it in doc/EN/virtual-can-env.md and doc/EN/virtual-lin-env.md.

The repository root gives away the build system. The top-level listing includes SConstruct and SConscript, the file names SCons uses for build scripts, along with a Console.bat helper and a .clang-format file, so formatting is tooled rather than tribal. The tree itself splits into app/, doc/, infras/, tools/ and a .workflow/ directory, which separates deployed code from host utilities and documentation.

A sensible first run follows the docs rather than a README snippet. Set up the environment per the build guide, bring up the virtual CAN environment, and use the bootloader document for the QEMU boot path, which the documentation index lists as a separate guide in English and Chinese. Bootloader configuration and host simulation are covered in their own BL document, so the simulation path is documented apart from flashing real hardware. Nothing in this flow needs a CAN interface, which is the cheapest way to find out whether the tree builds against your compiler before you commit an afternoon to it.

GPLv3 with a commercial escape hatch

Licensing is the decision that decides the audience. The project is dual licensed under GPLv3 and a commercial license, and the licence field on the repository says Other because the terms are a custom arrangement that GitHub cannot classify. The main page states that AS is free for evaluation and study, and that commercial use requires a commercial license, with the contact address [email protected] listed for that purpose. This is a legal summary of the project's own terms, not legal advice.

What that means in practice depends on how you intend to use the code. Evaluating the stack, studying the implementation, or running it on a bench with no distribution falls on the permissive side of the intent. Shipping it inside a product raises a GPLv3 question you need your own counsel to answer, and the fact that a separate commercial licence exists tells you the author treats that boundary as real.

The upgrade cost picture is mixed. The last push was on 2026-10-17, so the tree is being touched. The tagged releases are much older, with the most recent at 2024-01-14 and the two earlier ones in 2021. That combination suggests active code churn without a recent versioned milestone, which is normal for a single-author tree and means you should pin to a commit rather than expect a tagged dependency.

How a source tree differs from a commercial BSW supplier

The genuine alternative to AS is not another open source project but a commercial AUTOSAR Basic Software supplier, and the difference is structural rather than cosmetic.

A commercial supplier delivers the stacks as licensed binaries tied to an integrated configuration toolchain, and the invoice covers integration support, defect handling and the supplier's obligation to answer a request. AS delivers source trees plus a schema and PyQt5 JSON editor, a Python API, and Lua scripting inside the Qt host tool, with the tooling being genuinely part of the offering rather than a demo script. The supplier route trades licence cost for contractual risk; the AS route trades contractual risk for your own integration work.

Two further differences are visible in the tree itself. AS reaches hardware through adapters that are listed by name, Vector CanCaseXL, PeakCan and ZLGCAN for CAN and COM, USB2I2C and USB2SPI for LIN, which is a portability list rather than a certification against one vendor's interface. And the virtual bus plus QEMU targets mean you can develop most of the stack without a hardware bench at all, something a supplier toolchain usually leaves to a licensed simulator product.

Where AS is the wrong choice

There are clear cases where AS is the wrong tool, and they are worth naming before anyone spends a month on it.

The first is a production vehicle programme with a fixed certification timeline. Nothing in the project describes qualification evidence, validation suites or supplier quality processes, and the single author is also the licensor, which means a bus factor of one applies to both code and contractual questions.

The second is a team that needs a complete AUTOSAR stack rather than basic software modules. The scope is BSW, PC tools and supporting libraries. Runtime environment and application layer generation are not part of what the project describes, so a team expecting a full RTE path will not find one here.

The third is portability expectations. The platform table gives module coverage per MCU, and it varies. Only the AURIX TC3x7 entry lists DoIP and SOME/IP-SD, only the S12X entry lists CAN+LIN bootloading, and the TI CC27xx and MPC5634M entries omit the Memory Stack. Documentation pages exist for SecOC, E2E, XCP and TLS, but the table does not claim those modules run on every target, so verify coverage for your specific part before planning a schedule around it.

The fourth is team familiarity with the stack. The configuration workflow runs through a JSON schema and the asone tool rather than a widely known toolchain, so budget for learning time that a vendor with training and examples would partly cover.

Editorial conclusion

AS fits engineers who want an AUTOSAR-shaped BSW tree for evaluation, study or an internal CAN and LIN bench, and it fits the DoIP and SOME/IP work on AURIX TC3x7. It does not fit a production program that needs vendor certification, a support contract or a second maintainer, and GPLv3 obligations attach to any derivative you distribute. Before committing, check the licence file for the exact terms, confirm the build environment guide in doc/EN/build-env-setup.md matches your toolchain, and run the QEMU virtual CAN path listed in the platform table before touching real hardware.

Frequently asked questions

Official sources

1. autoas/as on GitHub
2. Issues
3. Project website
4. README
5. Releases