1. Introduction
1.1. Complexity in the mobility system
The mobility system is becoming increasingly complex due to the growing number of systems and their interactions. This complexity is further emphasised by growing demands for road safety, strict requirements imposed on systems and engineering processes used in their development. These high safety-critical requirements are mandated not only by customers but also by legislative bodies, such as the UNECE, and standardization organizations, like ISO. The requirements impose demands on the system itself (system requirements) as well as on the organization and engineering throughout various development phases (PMTA-Requirements). In this context, PMTA means Process, Methods, Tools, and Artefact Requirements. Connected Automated Vehicles (CAVs) must be capable of communicating and interacting with different systems within the mobility system (Reference Bita, Hovemann and DumitrescuBita et al., 2025b, Reference Bita, Hovemann and Dumitrescu2025a; Reference Luo, Zhang, Yang, Jiang, Wang, Wu and FengLuo et al., 2022; Reference Mpidi Bita, Ugur, Hovemann and DumitrescuMpidi Bita et al., 2026).
1.2. Resilience-by-design and resilience in operation
During development, CAVs are equipped with sensing and communication capabilities to gather more information about their environment, allowing for better situational assessment and optimal decision-making in operation. Consequently, automotive systems engineers cannot test and validate every scenario and situation during the development phase. To address this challenge, supporting properties such as resilience must be integrated early in the design phase: Resilience-by-Design. This characteristic enables vehicles to independently navigate and manage unexpected situations during operation: Resilience-in-Operation (Reference Bita, Hovemann and DumitrescuBita et al., 2025b).
1.3. Challenges in the concept phase
In the system design phase, also known as the concept phase, the basic systems architecture is defined based on the system requirements. It is advantageous to consider the essential system properties early in this phase because delaying them makes changes more expensive. Another challenge, after identifying the selected property, is measuring it. This means that the developer must be able to assess whether the property has been considered. One way to carry out this measurement is to use a so-called maturity model. This approach uses certain indicators to evaluate the maturity of the object under observation. This article presents a maturity model used to evaluate statements about system resilience in the concept phase of the automotive sector (Reference Bita, Hovemann and DumitrescuBita et al., 2025a).
1.4. Objectives and contribution
The purpose of this paper is to create a maturity model for assessing how resilient a system’s architecture is during its concept stage. Indicators for this evaluation will be defined to assist automotive systems engineering and streamline the evaluation process. Additionally, the maturity model seeks to establish a universal communication basis within the automotive sector, enabling the definition and pursuit of cross-system and cross-organizational goals. To ensure its practical applicability, experts are involved in the maturity level development process, providing their insights and assessments regarding the maturity levels.
1.5. Research design and contribution
The methodology used in this research is the Design Science Research Methodology (Reference Peffers, Tuunanen, Rothenberger and ChatterjeePeffers et al., 2007). This research approach is used in computer science and engineering. The method is suitable for this paper as it aims not only to systematically solve practical problems by developing innovative artifacts but also to investigate them scientifically. The research approach also determines the structure of the thesis. The individual process steps of the DSRM are shown in Figure 1.
Design science methodology according to Reference Peffers, Tuunanen, Rothenberger and ChatterjeePeffers et al., (2007)
This work is also structured according to the DSRM methodology. In the next chapter, the problem is identified and the requirements for the solution to be developed are derived. In chapter 3, existing models are analysed on the basis of a systematic literature review and evaluated to determine whether they fully meet the requirements and are suitable for our area of application. Since there is, to the best of our knowledge, no maturity model proved to be suitable in this context, we investigated methods for creating maturity models and developed a resilience maturity model on this basis. The model was critically evaluated in qualitative interviews with thirteen experts from the field of system design and adapted based on their feedback.
2. Problem analysis
2.1. Definition of resilience in the automotive context
Resilience is an important characteristic of future systems, particularly in networked automated driving. During the concept phase, cybersecurity and safety analyses are used to advocate measures that align with the concept of resilience. However, these analyses alone are insufficient to encompass the concept’s full scope. The independent focus on resilience within the automotive industry represents a new paradigm. Consequently, in both literature and discussions among experts, the term is typically associated with safety or cybersecurity. In the context of this paper, resilience according to Bita et al. is used (Reference Bita, Hovemann and DumitrescuBita et al., 2025b):
Resilience describes the ability of a system to maintain its intended functionality and availability despite unexpected disruptive events.
This definition was developed by analysing various definitions of resilience in the ISO standard from different areas of application. It thus offers a practical approach to the topic of resilience by design and enables the targeted application of the concept of resilience in the automotive context. This definition emphasizes two essential aspects of resilience: the reliability and availability of the system. In contrast to cybersecurity and safety, which only address certain types of risks, resilience is more comprehensive. Disruptive events include cyberattacks, environmental changes, internal failures, communication problems, and faulty data. In other words, events that affect the availability and reliability of a system in any way (Reference Bita, Hovemann and DumitrescuBita et al., 2025b). Furrer sees resilience as a requirement for dealing with general failure. The challenge is to take resilience into account in the system design phase (Reference Furrer and FurrerFurrer, 2022).
2.2. Behaviour of a resilient system
Understanding how resilient systems should function helps to derive the capabilities of a resilient system and formulate corresponding system requirements. Furthermore, once the system requirements are known, models can be developed to examine whether these are already being met in the system. In literature on resilience, an illustration is typically employed to convey the concept. While this figure is often presented in various modified forms, it fundamentally expresses the same idea. It outlines the phases a system should experience during a disruption. This graph is referred to as the resilience graph in this paper. The resilience graph from (Reference Bita, Hovemann and DumitrescuBita et al., 2025b) is used for this illustration. This representation is shown in Figure 2.
Resilience graph according to Reference Bita, Hovemann and DumitrescuBita et al., (2025b); Reference Mpidi Bita, Ugur, Hovemann and DumitrescuMpidi Bita et al., (2026)
2.3. Significance of the concept phase and role of system architecture
During the concept phase, the key decisions about the system are made. These decisions not only significantly influence the costs of realizing the system but also determine its operational behaviour. A central artefact in this phase is the system architecture, which is produced through the Systems Architecture Design processes within Systems Design Engineering. The purpose of the system architecture is to present an interdisciplinary, coherent and requirement-oriented structure that can be handed over to developers and systems analysts. Established methods are employed for describing and developing these architectures, such as the RFLP method (Requirements–Functional–Logical–Physical), that is a widely used approach in Model-Based Systems Engineering (MBSE) (Reference BaugheyBaughey, 2011) or the FAS method (Functional Architecture for Systems) used in automotive contexts (Reference WeilkiensWeilkiens, 2020; Reference Weilkiens, Lamm, Roth and WalkerWeilkiens et al., 2022). These methods support the structured decomposition of requirements into functional, logical and physical architectural decisions, thereby providing a transparent foundation for system development and analysis.
2.4. Resilience as system goal in the concept phase
If resilience is set as a development goal, the contractor must clearly understand which resilience attributes are to be considered, what outcomes are expected, and how the system should respond in the event of disruptions (Reference Bita, Hovemann and DumitrescuBita et al., 2025b). In practice, however, resilience is often discussed only qualitatively during the concept phase, for example, statements such as “the architecture is robust” or “we have redundancy”. The assessment heavily depends on individual expert judgments. To systematically evaluate and improve resilience within an architectural concept, a multi-stage maturity logic is required (Reference Bita, Hovemann and DumitrescuBita et al., 2025a). A level-based model (analogous to established maturity frameworks such as Automotive SPICE) provides comparability, repeatability, and enables targeted development of concepts along clearly defined criteria. Even when resilience weaknesses are identified in concepts, they are frequently described at an abstract level. It remains unclear which functions, components, or interfaces cause the weakness. For this reason, the system architecture itself is used directly as the input for analysis.
2.5. Separate domain analyses
In current practice, safety analyses (e.g., HARA/SOTIF) and cybersecurity analyses (e.g., TARA) are typically carried out as separate strands. Each produces its own set of requirements and countermeasures, but often without a consolidated view on how these measures jointly contribute to systemic resilience. As a result, the concept architecture is frequently shaped by parallel domain optimizations, while an integrated assessment of resilience as an overall property is missing (Reference Bita, Hovemann and DumitrescuBita et al., 2025a).
2.6. Lack of interdisciplinary comprehensibility for the evaluation
Resilience-relevant concepts and evidence are spread across multiple disciplines. Each discipline employs its own terminology, artefacts, and assessment criteria. To enable resilience to be evaluated and developed as a shared objective within the organization, The maturity Model should be comprehensible across disciplines with clear definitions, consistent terminology, and evaluation guidelines that can be interpreted by all participating engineering domains. Many assessment models fail in industrial practice because they are not embedded in the real development workflow (Reference Bita, Hovemann and DumitrescuBita et al., 2025a).
2.7. Field of action
System architecture designers need to assess the resilience level of the architecture, as it is to be incorporated. An architecture model alone does not explain the system’s resilience. To address this, a maturity model is necessary to evaluate resilience levels of a system architecture.
2.8. Requirement for the maturity model
The Automotive Resilience Maturity Model (ARMM) is intended to systematically evaluate and improve resilience in automotive system architectures. A maturity model not only enhances transparency but also establishes a standardized framework for comparing systems across various levels and organizations, thereby aligning efforts toward a common goal. This approach facilitates the planning, measurement, and improvement of system architecture development for automotive industry developers. The following requirements stem from key action areas and outline the essential properties and capabilities of the model:
Requirement 1: Level-based resilience assessment:
The model must support a structured, multi-level evaluation of resilience, aligned with established frameworks like Automotive SPICE (e.g., maturity levels 0 to 5). Each level must be clearly described to enable unambiguous assignment by automotive systems engineers.
Requirement 2: Traceability to architecture elements:
There must be clear traceability between resilience maturity assessments and specific system architecture elements (functions, logical and physical components). Such transparency is essential for validation, documentation, and approval processes.
Requirement 3: Linking with safety and cybersecurity analysis:
The model should integrate resilience as an overarching concept that connects to established analyses like HARA (ISO 26262, ISO 21448) and TARA (ISO/SAE 21434), capturing the contribution of safety and cybersecurity measures to overall system resilience.
Requirement 4: Interdisciplinary comprehensibility:
ARMM content must be accessible and interpretable across multiple engineering disciplines (e.g., software, hardware, safety, cybersecurity), fostering a shared understanding of resilience throughout the organization.
Requirement 5: Process integration:
The model must be seamlessly integrable into existing development processes. This includes clear definitions of when and how the model is applied, what input/output artifacts are required, and how the assessment aligns with development activities.
3. State of the art
To identify maturity models for the assessment of resilience using the system architecture, a Systematic Literature Review (SLR) is conducted. The search is executed across four major academic databases: Scopus, IEEE Xplore, SpringerLink, and Web of Science. The goal of the SLR is to evaluate the state of the art regarding the existing relevant maturity model against the research requirements. The following search string was applied to the title, abstract, and keywords fields to ensure a focused scope:
“Resilience maturity model” OR “resilience assessment model” OR “resilience assessment framework” AND “automotive” OR “connected car” OR “connected vehicle” OR “connected automated vehicle”.
A total of 119 initial records were identified (105 Scopus, 1 IEEE, 13 Springer, 0 Web of Science). After removing duplicates, 110 unique entries remained. Titles were screened for relevance to automotive resilience, excluding unrelated domains, reducing the set to 80. Abstracts were then reviewed for methodological fit with resilience maturity assessment in CAVs, narrowing the set to 24. After full-text analysis based on methodological contribution, ten publications were retained. Citation-based snowballing added one more source, (Reference McManusMcManus, 2007), resulting in eleven final publications. The evaluation results are summarized in Figure 3, aligned with the defined requirements.
Despite the critical role of resilience in CAV system architectures, there is a significant research gap regarding maturity models specifically designed to assess and guide resilience in these systems. Existing work has primarily focused on organizational resilience rather than technical systems. Even so, maturity models, well-established in other domains, offer structured methods for benchmarking and improvement. This section reviews key resilience assessment models, analysing their structure, scope, and limitations in the context of CAV system architectures. Rosenstatter et al. contribute the REMIND framework, which is one of the few models focused on the automotive domain. It classifies resilience techniques into Detection, Mitigation, Recovery, and Endurance, mapping them to vehicular system layers and attack vectors (Reference Rosenstatter, Strandberg, Jolak, Scandariato and OlovssonRosenstatter et al., 2020). While offering architectural guidance like Campean et al. (Reference Campean, Kabir, Dao, Zhang and EckertCampean et al., 2021), REMIND lacks a staged maturity structure and formal assessment methodology. Ouyang et al. (Reference Ouyang, Dueñas-Osorio and MinOuyang et al., 2012; Reference Ouyang and Dueñas-OsorioOuyang & Dueñas-Osorio, 2014) examine resilience in critical infrastructures, particularly electric power systems, using probabilistic modelling and multi-dimensional frameworks that integrate technical, organizational, and social dimensions. However, their work is not adapted to vehicular contexts. McManus et al. emphasizes strategic-level resilience assessment, proposing indicators useful for early development phases, but without technical system-level specificity (Reference McManusMcManus, 2007).
In summary, various resilience models exist, primarily at the organizational or infrastructure level, but there is an obvious lack of maturity models specifically designed to evaluate resilience in technical system architectures. This gap is particularly critical for CAVs, where structured, level-based methodologies are needed to guide the systematic development of resilient architectures. A dedicated resilience maturity model based on system architecture is therefore required.
Result of the systematic literature review
4. Automotive Resilience Maturity Model (ARMM)
4.1. Maturity model for assessing the resilience of systems architecture
Below, the Automotive Resilience Maturity Model is presented, which is based on the behavioural capabilities of a resilient system. This level-based assessment model characterizes the resilience capabilities of a system within the automotive domain. Figure 4 illustrates the proposed maturity model.
Automotive Resilience Maturity Model (ARMM)
The model defines six capability levels (CL0 to CL5), aligned with the model in (Reference Otter, Uschkurat, Durst and HenschelOtter & Uschkurat, 2024), representing the progression from complete vulnerability to disruption to fully autonomous adaptive resilience. The levels and corresponding evaluation indicators are described as follows.
CL0 (Not Resilient) denotes systems that exhibit no resilience behaviour. Upon disruption, such systems either experience irreversible failure or are unable to detect the disruption altogether. This level typically applies when monitoring or detection mechanisms are entirely absent or not functional within the architecture. At CL1 (Resilience Monitoring), the system becomes capable of detecting disruptions through embedded monitoring or diagnostic mechanisms. These systems can issue disruption flags indicating the system’s current resilience status. While detection is possible, mitigation or adaptation is not yet implemented. CL2 (Basic Resilience) introduces the concept of degradable systems. Upon disruption detection, system functionality is reduced in a controlled manner rather than failing completely. This level is characterized by the presence of degradation paths or fail-safe modes, which help maintain a reduced but stable operational state. CL3 (Functional Resilience) describes systems that, following degradation, can engage mitigation strategies to contain or recover from disruptions. Mechanisms such as redundancy structures, fallback strategies, or impact limitation are employed. The system may restore partial functionality, returning to a constrained but functional state. At CL4 (Operational Resilience), the system can autonomously recover its original performance level
, either fully or partially. The emphasis here is on evaluating the presence and effectiveness of recovery mechanisms embedded within the architecture that enable the restoration of nominal operation. The highest level, CL5 (Adaptive Resilience), characterizes systems capable of not only recovering but also adapting to improve performance beyond the original capability. This level includes adaptive mechanisms such as machine learning, self-configuration, and the integration of feedback data into ongoing system development. Indicators include learning capabilities and architectural support for adaptation.
The model is applicable across various architectural elements, including functions, subsystems, logical structures, and physical components. Furthermore, it can be methodologically integrated into existing automotive systems engineering, safety, and cybersecurity engineering practices. Through its structured levels and indicator-based evaluation, the model provides a practical framework for systematically planning, analysing, and enhancing resilience, particularly in the context of CAVs.
4.2. Integration of the resilience assessment in the systems design process
The maturity model is incorporated within the systems design process outlined below. Figure 5 depicts the ARMM in the context of a systems design engineering process. The figure illustrates how the model can be methodically incorporated into designing an automotive system’s architecture. The illustration is divided into the principal areas of system design and system analysis, according to INCOSE (Reference Walden, Roedler and ForsbergWalden et al., 2015).
Integration of ARMM in systems design engineering
The systematic procedure and required artifacts for resilience assessment based on system architecture can be derived from the architectural modelling process. This begins with the structured development of relevant architectural views, for example, using a general framework like RFLP. A system model consolidates these views, laying the groundwork for domain-specific analyses. Within systems engineering, system analysis supports life cycle decision-making (Reference Walden, Roedler and ForsbergWalden et al., 2015). The assessment of resilience is the focus here. The systems architecture serves as the central artifact, identifying resilience assets. These are architectural elements that hold value or contribute to system functionality and whose compromise could cause harm, hazards, or critical failures. Resilience assets may include systems, sensors, control units, communication interfaces, or software functions. Analogous to safety items (in HARA) and cybersecurity assets (in TARA), these elements often overlap in relevance, reflecting the inherent link between safety, security, and resilience. Accordingly, safety and cybersecurity concepts are important input artifacts for resilience assessment. Domain knowledge, past project data, and hazard catalogues further support asset selection. The actual resilience assessment process evaluates each identified asset based on the ARMM. The assessment is done level-by-level by examining resilience indicators in the asset’s architecture, such as detection mechanisms or degradation capabilities. Here, synergies with safety and security measures are again evident, mechanisms required in HARA or TARA can directly support resilience. Thus, existing safety and security analyses can strengthen the resilience evaluation perspective.
5. Interview result and discussion
5.1. Interview method
A qualitative expert interview was conducted to validate the Automotive Resilience Maturity Model. A similar procedure is used in (Reference Otter, Uschkurat, Durst and HenschelOtter & Uschkurat, 2024). The instrument used was the expert interview method, according to (Reference Meuser and NagelMeuser & Nagel, 2009). The methodology consists of the following steps: (1) selection of the experts, (2) conducting the interview and constructing the guidelines, and (3) evaluation and interpretation.
5.2. Selection of experts
The thirteen experts were participants from the field of systems engineering. The experts were expected to have expertise in systems design and more specifically in systems architecture design or systems architecture analysis. The sample was designed to cover a wide range of perspectives on architecture resilience assessment. It included both scientists from industry and employees working directly in industry.
5.3. Conducting the interview and constructing the guidelines
The interviews were conducted as guided, open discussions. This process consists of four steps: (1) preparing the interview guide, (2) conducting the interviews, (3) documenting the results, and (4) conducting a validation interview based on four main questions: (Q1) How do you rate the user-friendliness and comprehensibility of the maturity model in its current form? (Q2) To what extent do you believe the model addresses all relevant phases and dimensions of resilience? (Q3) Which aspects, dimensions, or elements do you feel are currently insufficiently covered or missing?, and (Q4) What specific feedback, suggestions, or proposals for improvement do you have for the further development of the model?
The first question aims to assess the model’s comprehensibility and user-friendliness from the experts’ perspective. The second question focuses on evaluating the completeness and coverage of the resilience concepts. The third question seeks to identify potential areas for improvement and necessary additions. The fourth question gathers practical recommendations from the experts. To foster a deeper conversation, particular emphasis was placed on interactive discussion. This approach created an interview atmosphere where participants felt encouraged to move beyond routine answers and share their subjective experiences and challenges.
5.4. Evaluation and interpretation
Experts found the model to be clear and understandable. The logical structure was positively highlighted, and the graphical representation of resilience behaviours, which forms the conceptual foundation of the model, was considered helpful in enhancing understanding. Despite the overall positive perception, several critical points were raised. A major concern was the lack of clarity regarding the model’s integration into the product development process. Respondents questioned whether the model is intended solely for the concept phase (used by system architects) or should also be applied during development phases by software or hardware architects. Several enhancements were derived from the feedback to improve the model’s clarity and practical utility. Chief among these was the need for a strong, process-oriented integration. As detailed in Section 4.2, the model has been explicitly embedded into the system development process, considering both the design phases and domain-specific analysis outputs.
Most interviewees confirmed that the model comprehensively addresses all relevant phases of resilience. This was attributed to its foundation in the well-established resilience graph, which was perceived as conceptually complete. However, the feedback also showed that the real issue was not about covering all the resilience phases, but about how well they fit together in the overall development process and with other related parts of the model. Some interviewees were unsure how risk analysis results lead to resilience measures or what actions and responsibilities stem from the maturity level determination. Additionally, there was confusion regarding the required artifacts. One expert clearly stated that it was not clear how risk analysis connects to the maturity model, causing confusion between viewing maturity modelling to assess capabilities and seeing risk analysis as a safety measure focused on functions. Furthermore, a lack of guidance was noted regarding which resilience strategies or methods correspond to each model phase. To address these issues, the model was enhanced with an explicit integration into the development process and a clear definition of expected input and output artifacts. As shown in Section 4.2, this includes not only process embedding but also the identification of relevant work products. Additionally, artifacts from related disciplines such as safety and cybersecurity were incorporated, thereby also supporting Requirement 3: Linking with Safety and Cybersecurity.
Further potential for the future development of the model lies in its integration with existing engineering tools. It was asked how the model could be integrated into existing MBSE models or tools, such as Cameo Systems Modeler or PREEvision. For example, SysML modules or plug-ins could be developed to integrate the maturity logic directly into architecture models. Support from AI-Augmented assistance systems (e.g., for risk identification or maturity assessment based on engineering data) was also discussed but remained open in the model. The interviews clearly show that the success of the model depends not only on its theoretical quality but also largely on the practical support provided by methodological and technical tools. Targeted operationalization through templates, examples, and tool integration is a key next development step to make the model industrially applicable and reusable.
6. Conclusion and future work
This paper introduces a maturity model designed to assess the capability of automotive system architectures to handle the increasing complexity and connectivity of modern vehicles. As resilience becomes ever more important in design, the model enables developers to account for this aspect at an early stage. The model was developed based on structured requirements derived from problem analysis. A comprehensive literature review revealed that existing models do not meet these requirements. Consequently, a new, staged model aligned with Automotive SPICE was conceived, allowing for the evaluation of resilience already during the concept phase. Its interdisciplinary approach enables engineers from various fields to apply it, and it is linked to established safety and cybersecurity practices such as HARA and TARA.
Through interviews with experts from industry and research, both the relevance and clarity of the model were confirmed. The interviewees agreed that all essential phases of resilience are covered: detection, mitigation, recovery, and adaptation, but also offered suggestions for improvement: better integration into existing processes, more specific application guidelines, and optimized tool support. Thus, the maturity model provides a solid foundation for systematically integrating resilience into the design of automotive system architectures.
However, further steps are required to demonstrate practical utility and scalability, including empirical validations in real vehicle projects. In the long term, the model has the potential to serve as a cross-industry standard framework for resilience assessment, like Automotive SPICE. This would make resilience a central development goal and could establish new professional profiles such as Automotive Resilience Engineer, complementing safety and cybersecurity experts.
To further promote adoption, practical application of the model in concrete case studies is essential to illustrate its benefits and clarify its role in the development process. Future work should also define precise indicators for each maturity level to enable objective measurement and comparability of resilience. A robust assessment methodology will guide users through consistent evaluations, identify resilience deficits, and document progress. Taken together, these developments are crucial for the effectiveness of the model, its widespread acceptance, and its status as a standard tool in automotive resilience engineering.
Acknowledgement
This research is funded by the German Federal Ministry of Education and Research (BMBF) in the project ConnRAD, grant number 16KISR029K. The contents of this publication are the sole responsibility of the authors.
Open access
