AWSIM gives Autoware a digital twin that already speaks the vehicle's ROS2 topics

A simulator that uses the vehicle's own topics and messages

Autoware is an open source autonomous driving stack. Testing a change to it on real hardware is slow, expensive and limited by daylight and weather. AWSIM is the digital twin answer: the README describes it as an open sourced digital twin simulator for Autoware, and calls it the best digital twin simulator for the Autoware project.

What separates it from a generic driving simulator is the interface. The feature list says ROS2 native communications and environments, and that it uses the same ROS2 topics and messages as the actual vehicle. That is the whole point of the design. A node written for Autoware does not need a translation layer to run in the simulator, so the same launch file and the same bag of recorded topics can drive a test in AWSIM and a test on the car.

The rest of the list shows how much of the stack the simulator takes seriously. The vehicle dynamics are optimised for Autoware, and it supports Autoware's vehicle control mode. There is ray tracing lidar sensor simulation, Open CV camera sensor simulation, and IMU and GNSS sensor simulation. Point cloud generation is there, so a perception node that expects a point cloud topic gets one.

The audience is Autoware developers and integrators, plus anyone writing scenario tests against the stack. The repository topics name autonomous-driving, autoware, ros2 and unity, and the primary language is C#.

It is a Unity project, with a pinned editor version

AWSIM is not a simulator you install as a package. The repository layout is a Unity project: there is an Assets directory, a Packages directory, a ProjectSettings directory, an AWSIM.slnx solution file, and a README_img folder. The README also states the Unity version outright, 6000.0.61f1, and the feature list repeats it as its own line.

That pin matters more than it looks. Unity projects carry their engine version in the project settings, and a different editor version can rewrite assets and change rendering behaviour, which for a simulator with sensor models is a correctness problem rather than a cosmetic one. A team adopting AWSIM should treat 6000.0.61f1 as the supported editor and upgrade deliberately.

The repository also contains a cyclonedds_config.xml at the top level, which is the configuration for the DDS middleware that carries the ROS2 traffic between the Unity process and the Autoware nodes. A single file at the root is a hint that the communication setup is one deliberate step rather than something you discover later, and it is also the first place to look when topics do not connect.

Documentation is built with mkdocs, with the docs directory and a mkdocs.yml at the root, and it is published at the Autoware Foundation GitHub Pages site rather than in the repository alone. The tutorial section points at a Quick Start Demo page as the first thing to try.

Sensor models, a G29 wheel and the driving controls

The sensor line-up covers the three sensing paths an Autoware vehicle depends on. Lidar is simulated with ray tracing, which is the expensive and accurate option: it produces a point cloud that reflects the geometry of the scene rather than a synthesised depth pattern. Cameras are simulated with Open CV, and IMU and GNSS are simulated as well, which means localisation nodes have plausible inputs rather than empty topics.

A point cloud generation feature is listed separately, and combined with the lidar entry it points at a pipeline where raw or accumulated point clouds can be produced for perception testing.

For human-in-the-loop work, the simulator supports Logitech G29 steering wheels, and the vehicle dynamics are described as optimised for Autoware with support for Autoware's vehicle control mode. That combination is what makes the simulator usable for regression on driving behaviour rather than only for sensor replay.

Two further capabilities are worth separating out. There is support for V2I development, which is the vehicle to infrastructure side of cooperative driving. And there is support for ASAM OpenSCENARIO, which the README ties to connecting scenario simulator v2, the standard format used for describing traffic scenarios in simulation. OpenSCENARIO support is what lets an organisation reuse scenario descriptions written for other tools instead of authoring each test inside Unity.

Controllable time scale and fixed seeds make runs repeatable

Simulation is only useful for regression if two runs of the same scenario produce the same result, and AWSIM addresses the two things that usually break that.

The first is time. A controllable time scale is listed as a feature, so a scenario that would take twenty minutes of driving can be run faster, or slower when you want to watch a manoeuvre in detail. For an autonomous driving stack where most of the cost is in simulation hours, this is the difference between a test suite that runs on every change and one that runs occasionally.

The second is randomness. The README lists random traffic simulation with the note that seed values can also be fixed. Random traffic is what makes a scenario interesting, and fixed seeds are what make a failure reproducible. A scenario that fails at seed 41 is either handled or it is noise, and the ability to pin the seed is what lets a team tell the difference.

Other customisation comes through code. The README lists a focus on customizability through coding, a simple and highly expandable layered architecture, and the ability to control the execution order of C# code independent of Unity's script execution order. That last one is a real engineering detail: Unity decides the order in which scripts run, and in a simulator where a sensor must be sampled before a planner consumes it, being able to impose the order explicitly removes a class of intermittent, hard to reproduce failures.

Rendering is switchable between HDRP and URP, so the same scenario can be rendered with the high fidelity pipeline or the more lightweight one, which is the usual compromise between visual quality and how many simulations you can run in parallel.

Three licences in one repository, and the strictest one is on the docs

The licensing is unusual and worth reading before you do anything with this repository. The README sets out the AWSIM License, which applies to the autowarefoundation/AWSIM repositories and all content contained in the Releases:

- code : Apache 2.0 - assets : CC BY-NC - docs : Prohibit public hosting of documents under `/docs`

Three different terms in one project. The code, which is the part most integrators care about, is Apache 2.0. The assets, meaning the 3D models, maps and textures, are CC BY-NC, so they can be reused with attribution but not for commercial purposes. The documents cannot be publicly hosted, which is the term that trips people up: it stops you from copying the documentation to a public wiki or a public docs site, and the README points to the LICENSE file for the exact wording.

There is a copyright line for 2025 TIER IV, inc, which is a leftover from the project's earlier life. The README also carries an important notice at the top: AWSIM has been transferred from TIER IV to the Autoware Foundation GitHub organisation at 2026-05-07.

So the current state is a project that began inside a company and now sits in a foundation organisation, with the licensing settled but the asset terms still carrying a non-commercial restriction that a commercial simulation user needs to read closely. This is a licensing fact, not legal advice.

From a company project to a foundation project

The governance change is recent and visible. The transfer to the Autoware Foundation organisation happened on 2026-05-07, and the repository is not archived with the last push on 2026-10-20, so the work continued after the move rather than stopping at it.

The release history spans the transition. v1.3.1 was published on 2024-11-15, v2.0.0 on 2025-08-01 and v2.0.1 on 2025-10-31. The 2.0 release landed before the move to the foundation, which means the current generation of the simulator was shaped while it was still a company project, and the foundation inherits it rather than rewriting it.

There is external recognition as well. The README notes that AWSIM won the Grand Prize in the Innovation Award category of the Industry at the 17th Unity Awards, with a link to the announcement. Award results are not a technical argument, but they are a signal that the project is known outside the Autoware community.

For an adopter, the practical question is what changes with the foundation. The code licence is already permissive for the code, the assets are non-commercial, and the docs cannot be publicly hosted. What the transfer does not change is the Unity version pin, the ROS2 interface contract, or the fact that the simulator lives in the same organisation as Autoware itself, which is the natural place for a simulation tool to sit.

Where AWSIM is the wrong tool

The clearest wrong case is a team that is not already on Autoware. The design assumes the Autoware stack, its topics and its messages, and its vehicle control mode. If your autonomous driving stack speaks something else, the integration work is not a configuration step, and you would be rebuilding the interface that makes AWSIM valuable in the first place.

The second wrong case is commercial redistribution of the assets. CC BY-NC on the assets rules out using the simulator content for commercial purposes, which narrows who can build on top of this for a product. If that is your situation, the licence is the blocker, not the technology.

The third is a team without Unity capacity. AWSIM is a Unity project with C# scripts, and the project itself highlights the value of controlling script execution order, which is the kind of work that needs someone who knows the editor. There is no command line distribution described in the repository, no package manager install and no container image listed among the top level entries, so adopting it means adopting Unity as part of your simulation stack.

Finally, the fidelity question. Ray traced lidar and Open CV camera simulation are appropriate for testing perception pipelines and planning behaviour, and they are not a substitute for validating on real hardware. AWSIM removes the vehicle from the early loop of development. It does not remove it from the last loop, and the README does not claim otherwise.

Editorial conclusion

Adopt AWSIM if your team already runs Autoware and needs scenario work without a real vehicle, since the simulator uses the same ROS2 topics and messages as the vehicle and its vehicle dynamics are tuned for Autoware. Do not adopt it if you need to distribute the documentation, because the licence prohibits public hosting of the documents under /docs and the assets are CC BY-NC. Before you start, pin Unity 6000.0.61f1 as the README specifies, read the Quick Start Demo page linked from the tutorial, and check the licence file yourself, since the repository reports three different terms for code, assets and docs.

Frequently asked questions

Official sources

1. autowarefoundation/AWSIM on GitHub
2. Issues
3. Project website
4. README
5. Releases