1. Overview

This proposal details changes towards the project structure, project lifecycle and the responsibilities of the impacted roles throughout. The goal of this proposal is to achieve a more flexible, transparent approach to development of standards, with fewer unnecessary hurdles and improved long-term planning and transparency.

It is proposed to apply these changes directly in a pilot initiative targeting ASAM’s Simulation Domain.

The key motivator for this proposal is feedback from many of ASAM’s more recent projects, where participants are often used to more agile-based workflows.

The proposal aims to address some key issues within the current approaches:

  • Onerous and opaque proposal process that leads to inadequate project planning (participant commitments, feature timelines)

  • Inflexible project structures (one project = one standard) that hinder alignment amongst products

  • Excessive review length

  • No consistency across projects for ASAM products. If there is no project, there is no one for technical discussions around new features outside of the office.

  • Long release cadence, little planning beyond "this project". No long-term planning for single standards, nor for a set or the portfolio

  • Scope creep - project proposals are often "wish lists" and not anchored by realistic commitments

  • Dependency on tri-annual TSC meetings for approvals lead to planning around TSC meetings with little benefit

  • Releases are often postponed due to feature creep. As the overhead to new releases is so high, the oft-selected approach is postponement. This causes damage to the portfolio overall, making alignment more difficult. Discussions are weighted by the heavy implications of a release. This is suboptimal for many of ASAM’s standards, where a more agile approach would be more aligned with the state of the industry.

  • Commitments are currently mostly meaningless for project planning

  • Alignment across standards currently only occurs if there are activities for the impacted standards ongoing. Often there are not such parallel activities, meaning alignment does not happen.

The changes proposed are iterations on the existing processes. The most notable changes being proposed:

  • Each domain has a static domain group, a group of experts or stakeholders interested in activity for a given domain.

  • Projects should have a shorter average duration, targeting individual features, use cases or fixes.

  • Project proposals are slimmed down, commitments are less monolithic, more fine granular and thus easier to make/approve

  • The review phase is compacted, what previously happened sequentially now happens in parallel.

  • Review is focused on what changed, facilitating better collection of feedback

  • More, shorter, TSC meetings rather than fewer, longer ones to better cater to project demands and allow greater focus on a smaller list of topics each meeting

2. From domain to projects

Some key terms.

2.1. Domain

ASAM’s portfolio of products is divided into domains. A domain refers to a specific area of interest or application within the mobility industry. The domain is not exclusive, standards may be used for applications/use cases in other domains.

2.2. Product

A standard, concept paper, implementation, tool or other publication by the ASAM organization. All products are developed in ASAM projects. A standard, as a subset of a product, shall have a dedicated CCB for maintenance and coordination of its continued development.

The large majority of concepts addressed in this proposal target standardization efforts (including concept work). Software development is out of scope of this proposal. Some aspects of the changes proposed in this document do not apply to projects that do not yet leverage ASAM’s docs-as-code workflows. The underlying principals can be applied throughout, however.

2.3. Project

A project at ASAM is a temporary endeavor undertaken to achieve a particular aim with a definite beginning and end. A project may be anything from an initiative to write a whitepaper or concept paper, a study group to develop knowledge, or a standardization effort to develop new standards or improve on existing standards. ASAM standards are developed (or further developed) exclusively in projects. If relevant, external contributions to standards (e.g. in the case of open source standards) must undergo typical review and approval within a project prior to integration. A project:

  • is initiated based on an approved proposal

  • may address features across one or more products.

  • is structured into subgroups

  • has 1..n subgroups.

  • is complete once all criteria listed in the proposal are satisfied. This includes the completion of any relevant features/issues across products, the review has been completed (see Section 4.3) and approvals by impacted CCBs have been confirmed.

  • Project end is not equivalent to a direct release (or releases). Releases are dependent on a product’s roadmap and may vary. Releases should be defined for each product’s roadmap. See Section 4.4 for further details.

3. Roles & responsibililties

This listing is not exhaustive. It emphasizes key points and/or items that may differ from ASAM’s existing documentation (this includes the TSC Guidelines, the ASAM RASI and the ASAM Project Guide).

3.1. Project Management Office (PMO)

The Project Management Office (PMO) is responsible for coordinating project logistics, monitoring project health, managing administrative tasks, and supporting agile processes throughout the project lifecycle.

  • organization/coordination of project & subgroup meetings

  • Overall process monitoring for projects and products (e.g. the ASAM development and release processes) (similar to a scrum master in agile terminology)

  • Monitor and make available project health metrics (agile metrics such as burn down/burn up charts, commits, meeting participation, spill-overs)

  • Accountable for issue & milestone maintenance (issue triage, ensuring issue weighting and prioritization)

  • Manage service providers (administrative, controlling, obtain approvals)

  • Responsible for service provider controlling

  • Reporting to TM/Project on metrics and budget

  • Manage project templates (issues, proposals)

  • Onboarding of new participants

  • Participate in CCB (non-voting) when requested

3.2. Technology Manager

The Technology Manager (TM) oversees technical coordination, manages the project infrastructure, ensures budget approvals, and facilitates alignment across domains and projects.

  • Manage and maintain deliverable pipeline / overall infrastructure

  • Manage ASAM editorial templates

  • Responsible for coordination of technical topics in projects at the domain/proposal level

  • Accountable for proposal and issue dependencies, prioritization and alignment

  • Accountable for issue/proposal backlog

  • Manage service providers (technical)

  • Participate in CCB (non-voting)

  • Facilitate cycle planning

  • Facilitate, moderate and maintain Domain Groups

3.3. Domain group

A standing body addressing a specific technical domain within ASAM’s portfolio, focused on the development and maintenance of standards within that domain.

  • Operates continuously without a defined end.

  • Analogous to e.g. an Expert Group within Eclipse or Correspondent Membership within an ISO TC.

  • Functions as an open, moderated mailing list managed by the ASAM office to inform interested experts of the latest developments, the initiation of new activities or calls for contributions.

  • A domain group is not just intended as a passive entity.

  • Enrolled experts are invited to contribute feedback on issues, reviews and project proposals. Active participation may vary across domains.

  • Participation is open to anyone, including non-ASAM members.

  • A Domain Group is intended to reduce the barrier of entry to ASAM’s community.

  • Joining/leaving a domain group should be possible via a 'sign-up link' or a checkbox on the website.

  • A Domain Group may serve as 3rd level of support for technical questions towards a product. Note that this could also be performed by a CCB and is a topic for later clarification.

  • Each Domain Group encompasses 1 or more Change Control Boards (see Section 3.5), dedicated to individual standards within the domain.

  • A Domain Group may have an additional, optional Section 3.4

This is not yet a formal body at ASAM. It should be noted that simple mailing lists for each domain do already exist, but are mainly used for marketing purposes. These could serve as the basis.

3.4. Coordination Group

A body dedicated to high level, cross-product alignment within a given domain.

  • The TSC is responsible for defining the need for such a body, this may vary from one domain to another.

  • The initiation of such a body may be requested by the Domain Group.

  • It is proposed that the naming for these bodies adopts the previously employed convention of "Coordination Group: <Domain name>".

  • A Coordination Group shall consist of at least 2 representatives of each product-specific CCB within the domain, one ASAM Office Technology Manager, one TSC member and, if relevant, the Project Management Office.

  • Within the Coordination Group, only ASAM members have voting rights.

  • If present, a Coordination Group is tasked with overall release management across the domain and coordination of products within the domain.

3.5. CCB

A subgroup of experts for a dedicated standard. The Change Control Board (CCB) is responsible for internal alignment of topics, release management and approval/review of pull requests. The CCB is an ongoing body. The need for a CCB (or lack of) for a specific product is identified by the domain group and confirmed by the ASAM TSC. For example, some standards may not require continued coordination due to maturity. A CCB:

Tasks include:

  • proposal, issue and MR/PR maintenance (supported by the PMO)

  • Milestone monitoring and planning

  • Release management

  • shall consist of at least 3 ASAM member companies represented by experts on the product, an ASAM TM and optionally the PMO.

  • only ASAM members have voting rights.

  • participating experts should have participated in at least one prior ASAM project for the respective product

  • provides approval for a completed project for release (including mapping of the respective features to a release milestone). For major/minor releases TSC approval is also required.

  • requires regular participation in CCB meetings.

3.6. TSC

The TSC decides about and controls all development projects at ASAM, primarily the development of standards (click for details).

  • is responsible for the definition and structuring of ASAM’s portfolio at the domain level (and hence the initiation/maintenance of Coordination Groups)

  • is responsible for budget priorisation, if technical budget becomes an issue

  • is responsible for budget approvals and service provider contracting

  • is informed of project budgets and project controlling

  • is responsible for project approvals

  • may request involvement or input by additional Domain Groups to projects/proposals for alignment across domains.

  • is informed of new maintenance releases

  • is responsible for new major/minor releases

  • may request specific epics/issues/features within projects be detailed in further concept development prior to implementation/integration in a standard.

  • is informed of the project plan and release roadmap (including breaking changes).

  • should participate in review of release candidates, with a focus on technical feasibility and overall quality.

  • may delay a release or request removal of features during the review period

  • should ensure representation in active Coordination Groups

Many of the statements in this proposal are based on an increased TSC meeting cadence. It is proposed that the TSC meet monthly in a 1-2 hour slot for project-related approvals and/or discussions. Should this not be adopted, changes may need to be made to the changes proposed here, such as revising the project proposal approval process. Additional TSC meetings in accordance with the current mode will likely still be beneficial for discussions related to strategy and overall alignment.

3.7. Escalation

Any participant of any ASAM body may escalate a topic to the next level if they feel that it is not being addressed sufficiently or they feel that additional factors need to be discussed or a decision is questionable.

At the project level, the first instance of escalation is from a project subgroup to the project. From here technical, product-specific topics may be escalated to the CCB, other topics should be brought to the ASAM office.

4. The project lifecycle

Summary

Each domain at ASAM has a standing domain group. Within that domain group each existing standard has a standing CCB. When an individual, a company or any stakeholder wants to extend an existing standard, make fixes or create a new standard within the domain, they submit 1..n proposals to the domain group.

A proposal formulates a goal, use cases and/or requirements and defines the scope for any development activity. It may cover 1..n individual standards. It also includes commitments by participants and a timeline. The proposal is iterated on within the domain, based on feedback from experts in the domain group, TSC, CCB and the ASAM office. A proposal is submitted to the CCB and the TSC for approval. On approval, a proposal transitions to active development and becomes a project.

When a project is feature-complete, its developments are shared with the CCB and the domain group for review. When the CCB approves the developments, a project ends and the developed content is assigned to a release milestone for integration into an upcoming new version release of the standard or standards it affects.

When the CCB for a respective standard decides to release a new version, based on the release roadmap, all planned features that were previously assigned to that release milestone are integrated into a release candidate and a review of this new version is initiated. Once both the CCB and the TSC have approved the release candidate, it is formally released by the ASAM office as a new version.

project lifecycle.drawio
Figure 1. The project lifecycle

4.1. Project proposal

A high level description of a feature, initiative, use case or request. Also analogous to an epic in agile terminology.

A project proposal formulates:

  1. a problem statement

  2. relevant domains/standards that are affected

  3. in-scope, i.e. features and changes to be implemented in the affected standard(s)

  4. out of scope (explicit topics that are not addressed)

  5. duration (start/end)

  6. estimated effort

  7. project lead

  8. commitments

  9. completion criteria.

Depending on the infrastructure being used, a proposal may just be an issue labeled accordingly.

Key points:

  • The phase is extended to account for what was previously termed 'ideation'.

  • The input to the proposal phase is an idea.

  • An idea can be submitted by anyone

  • Proposals are subject to a proposal process documented in the project guide.

  • A proposal must be presented during a proposal workshop.

  • The key output of this phase remains a written proposal in accordance with the criteria defined above

  • The phase ends on approval of the written proposal by relevant CCBs and the TSC.

proposal.drawio
Figure 2. The revised proposal phase for projects

Roles Involved: Project Management Office (PMO), TM, Domain Group, TSC

Responsibilities:

  • The PMO organizes initial meetings to facilitate the creation of the project proposal, providing templates and guiding participants.

  • TM reviews the proposal for budget alignment, technical feasibility, and infrastructure requirements, coordinating with Domain Groups for cross-domain consistency.

  • CCB participates in scoping discussions, providing product-specific insights and ensuring alignment with ongoing projects.

  • Domain Groups are able to provide feedback on relevance and scope, bringing in expertise from the specific technical domain.

  • The TSC reviews the proposal to ensure alignment with ASAM’s strategic objectives and domain-level structuring, potentially suggesting cross-domain alignment.

4.2. Development

The development process in the project guide already outlines a cyclical approach to development. Development is primarily driven by discussion and contribution to "issues". Participants are encouraged to directly contribute solutions to issues in the form of MR/PRs to accelerate development. The development cycle can be reduced to:

development.drawio
Figure 3. The development phase in a project.

The majority of details on the development process are outlined in the project guide, some key additions should be made to the guide to better align with the changes in this proposal. The project guide should provide a clear framework for projects on how to work, to ensure anti-trust compliance as well as sufficient transparency for the various bodies within ASAM to perform their duties (CCB, CG, TSC, …​).

In contrast to the current working mode, the end of a project is not necessarily coupled to a new release. Rather the output is 1..n merge/pull requests to 1..n standards. When these are actually integrated into a new version of the respective standards is up to the individual product roadmaps and in the coordination of the respective CCB. A prerequisite for this is approval by all required parties.

Roles Involved: PMO, TM, CCB, Domain Group, Coordination Group (if needed)

Responsibilities:

  • TM coordinates technical topics across domains, defines proposal dependencies.

  • A Coordination Group, if needed, handles high-level alignment within the domain, supporting overall release management across multiple products.

  • The PMO monitors project health, ensures timely issue and milestone maintenance, and coordinates with service providers for implementation support.

  • The CCB manages the approval of pull requests, conducts internal alignments, and oversees milestone monitoring.

  • Domain Groups serve as a forum for ongoing feedback, allowing members to review progress and suggest improvements.

4.3. Review

  • The current review is excessively long and some parts seldom lead to additional feedback.

  • Experiences in the past few projects have shown that it is unnecessary to adopt a sequential approach to review as is currently the case (project→member→office→NS→TSC).

  • Instead, a two-step approach is proposed:

    1. Feature-review: Technical review of specific features prior to integration into the standard

      • A feature review should take place when a proposed solution is approved by the project group and there is initial agreement by the relevant CCB(s).

      • A feature review takes place in a merge/pull request directly

      • Feature-review ends on approval voting by the respective CCB(s)

      • A feature-review is open and accessible to all levels up to a domain group.

        In order to achieve the correct level of information for potentially interested experts, it is deemed important to make the information available but not overwhelming. A regular newsletter could be used to inform the domain group of the latest activity in a project, this should address updates in the domain and include open merge requests that are open to review, proposals that are under discussion and the latest releases. The information in this newsletter should be defined by the CCBs of the respective products. AS ASAM already has a newsletter, a more flexible configuration should be enabled, that allows user-specific selection of topics of interest.
        review feature.drawio
        Figure 4. The release-review process

    2. Release-review: Review of a release candidate for a new version of a standard. Editorial changes only.

      • A call for review should clearly outline which proposals were addressed, what features in individual standards were implemented/extended as a result and what changes/additions were made to the deliverables.

      • A call for release-review shall be shared publicly and with the TSC

      • The TSC or the CCB may postpone integration of a feature from a project if review feedback is not sufficiently addressed or other critical issues arise.

      • Completion of the release-review phase for a project is dependent on approval by the CCBs of the impacted products and, in the case of major/minor changes, TSC approval.

        review release.drawio
        Figure 5. The release-review process

Additional points:

  • The native speaker review is not always necessary (minor feature reworks or bug fixes).

  • The CCB of a project may determine the need for a formal native speaker review.

  • The office may involve a contracted third party at its discretion.

Roles Involved: CCB, TSC, Domain Group

Responsibilities:

  • The PMO facilitates the review process and makes information and metrics available to all parties

  • The CCB leads the review phases, reviewing pull requests

  • Domain Group members participate in feedback cycles, helping refine and validate solutions against domain-specific requirements.

  • The TSC reviews the release candidates, focusing on technical feasibility, strategic alignment, and quality assurance, making final decisions on release approvals.

4.4. Release

  • A product roadmap shall clearly communicate the release milestones.

  • A release shall include a concise set of release notes (see e.g. OSI), in compliance with a prescribed template

  • Should a release be delayed, the release milestone shall be updated accordingly and the TSC, as well as the domain group informed.

  • A release is subject to approval by the CCB and in the case of major or minor version releases, the TSC.

  • On release, ASAM informs the respective Domain Group.

Roles Involved: PMO, TM, CCB, TSC, Coordination Group (if applicable)

Responsibilities:

  • The PMO oversees release documentation

  • The TM handles overall infrastructure updates and ensures alignment across the deliverable pipeline.

  • The CCB manages minor updates and issues arising post-release, working with Domain Groups to gather user feedback.

  • The TSC monitors the release roadmap and may request revisions based on emerging strategic needs, ensuring continuity and alignment across ASAM’s portfolio

release.drawio

5. Involvement of service providers (SPs)

As it stands today, service providers are contracted on a per project basis. A project may at any time request a budget for a given topic from the ASAM TSC. On approval, the ASAM office publishes a Request for Quotations. The selection of service providers is performed by the project and approved by the TSC.

The revisions to the project process described so far, with shorter-lived and/or more fine-granular projects would make this approach difficult. It is proposed that contracting for service providers under this revised approach occurs at two levels.

  1. Product level: Modelling and implementation tasks. It is currently deemed unrealistic to have a centralised approach to these due to the strongly varying approaches selected by each standard.

  2. Domain level: Technical documentation, to support consistency across products

Contracts should be for a fixed time-period (1 year). Contracts should be based on time and material (as is already the case). Controlling and/or modification of the allocated budget should be performed at each ASAM TSC.

The contracts above may not suffice for larger projects or development initiatives, for example the expertise required may surpass that contracted in the above. In such a case, a project may request an additional budget from the TSC.

Implementation tasks for products and associated budgets should also include implementation of checker rules, where applicable.

6. Applying the proposal

There are two opportunities presented by the current ASAM project pipeline to pilot the changes proposed herein.

  1. The next 'wave' of OpenX projects is currently in early planning stages, this is a rare opportunity to leverage the 'lull' in the OpenX project roadmap to more closely align the individual products

  2. The follow-up for ASAM Test Specification is currently being detailed out. The need for an agile approach that supports inter-product alignment would be well served with the proposed changes.

6.1. OpenX

openx.drawio
Figure 6. A first timeline for the OpenX pilot in accordance with the changes proposed
A first set of proposals (documented as issues) is currently being collected here. This list of proposals is open to everyone, feel free to add new proposals or join the discussion on existing ones.
openx project structure.drawio
Figure 7. A first sketch of the structure of the OpenX pilot
Checker rule definition for individual standards is seen as part of standards development and thus a part of this proposal. Implementation is expected to be part of the product budgets.

TODOS:

  • Budget requirements (PMO, product-level support, technical documentation for openX)

  • Moving the existing proposal content from e.g. OpenDRIVE 1.9, CityGML and OSC DSL to the link above

  • Agree which standards are initially in scope. Currently it is proposed that we begin with OpenDRIVE, OpenSCENARIO XML, OpenSCENARIO DSL and OSI. By Q3 we would like to have integrated OpenMaterial, OpenCRG, OpenODD and OpenLabel.

  • Role assignments - Project lead for each of the topics in the link above, CCB for each product (leading to the coordination group), ASAM office

  • Drafting of a first release roadmap based on the features outlined in the link above.

  • Infrastructure onlining

  • OpenX Licensing

7. Open questions

A few questions require additional effort to detail out. Many of these are already relevant in the existing processes. These include:

  1. Definition of project metrics/KPIs

  2. Knowledge management across products, projects and domains

  3. Keeping the membership informed - domain newsletters

8. How to get involved?

There are various possibilities for an interested expert to get involved in the ASAM community:

  • Sign up for the ASAM newsletter (see note)

  • Submit a proposal

  • Create a product-specific issue or feature request in the respective repository

  • Submit a merge/pull request directly implementing a new feature or providing a fix

  • Spread the word!

  • Join in a project

  • Give feedback on a proposal or during a review

Appendix A: Supporting ASAM members

This section collates (and credits) representatives from ASAM member companies responsible for the preparation of this proposal. It is not exhaustive. If you are missing from this list, please reach out to benjamin.engel@asam.net

  1. Michael Schwarzbach, BMW

  2. Carlo van Driesten, BMW

  3. Andreas Rauschert, BMW

  4. Marc Semrau, CARIAD

  5. Esther Hekele, Hexagon

  6. Clemens Linnhoff, Persival

  7. Philipp Rosenberger, Persival

  8. Gil Amid, Foretellix

  9. Jakob Kaths, Vector

  10. Pierre Mai, PMSF IT Consulting