Ensuring ISO 26262 Functional Safety with SHARC in Automotive Systems

ISO 26262 is the international standard for functional safety in road vehicles. It provides a rigorous framework to manage safety from the concept phase through design, implementation, verification, and validation. Key aspects of ISO 26262 include:

• Hazard Analysis and Risk Assessment: Identifying potential hazards (e.g. unintended acceleration, loss of steering) and classifying their risk levels. This leads to assigning an Automotive Safety Integrity Level (ASIL, A to D) to each safety goal, with ASIL D being the most stringent.
• Safety Requirements and Design: Developing both functional and technical safety requirements to mitigate hazards, and designing the system with appropriate safety mechanisms (like redundancies, monitors, fail-safes) to meet those requirements.
• Verification and Validation: Ensuring through analysis, reviews, and testing that the design indeed meets the safety requirements and will reduce risk to acceptable levels. This includes methods like Failure Mode and Effects Analysis (FMEA), Fault Tree Analysis (FTA), hardware fault metrics (like SPFM, LFM, PMHF), as well as extensive testing on prototypes and final products.

For automotive engineers and functional safety managers, complying with ISO 26262 is a complex challenge. Traditional development processes (often represented by the V-model) involve many distinct steps and handoffs between teams. One team might create system models, another handles hardware design, another does software, and yet another performs safety analysis. Ensuring that safety requirements are consistently addressed across all these domains — and that no critical detail slips through the cracks — can be daunting. Miscommunication or late discovery of a design flaw can lead to costly iterations and delays in time-to-market.

In this blog post, we explore how the SHARC framework can dramatically streamline this process. SHARC (Simulation and Verification of Hierarchical Embedded Microelectronic Systems) is a model-based design and verification framework built with ISO 26262 compliance in mind. It aims to bring all the crucial elements of safety-driven development into a unified environment. By doing so, SHARC helps automotive teams catch problems earlier, reuse proven components, and verify functional safety continuously from concept to implementation. Let’s dive into what SHARC is and how it supports ISO 26262 in developing automotive embedded systems.

SHARC is an integrated framework that ties together system modeling, simulation, and verification to meet the demands of functional safety standards. Developed as an Eclipse-based tool (with Papyrus UML modeling at its core), SHARC was designed to address several pain points in the safety-critical automotive design process:

• Early Verification: A key goal of SHARC is to enable early simulation and testing of system behavior, rather than waiting until late-stage prototyping. By validating design decisions early (even at the model stage), engineers can uncover safety issues long before hardware is built.
• Seamless ISO 26262 Workflow Integration: SHARC aligns with the ISO 26262 V-model lifecycle. It introduces a “mini V-model” within the traditional development flow to close the gap between abstract system design and detailed implementation. This means safety analysis, design refinement, and verification are tightly looped together, ensuring consistency at every step.
• Bridging Organizational Gaps: In many companies, system architects, hardware designers, software developers, and safety engineers use different tools and languages. SHARC’s framework bridges these organizational gaps by using a single unified model and toolchain. The system design, safety analyses, and verification tests all reference the same source model, reducing misinterpretation and errors from manual data transfer between teams.
• Reuse of Components and Safety Mechanisms: Modern automotive projects rarely start from scratch—there are well-tested IP blocks, libraries, and prior safety solutions to draw on. SHARC encourages reuse of trusted components and even entire safety concepts. For example, if an engine controller in a previous project had a well-validated safety mechanism for sensor failures, SHARC makes it easier to import that mechanism into a new design. Reusing proven components not only saves development time but also carries over their known reliability, aiding compliance.
• Scalability to Complex Systems: The “Hierarchical” aspect of SHARC’s name highlights its support for complex, multi-layered systems. You can model a large system as a hierarchy of subsystems (for instance, a vehicle could be broken down into powertrain, chassis, infotainment, etc., each further subdivided). SHARC’s approach scales to these complex architectures, helping manage the complexity by verification at both subsystem levels and the full system integration level.

In essence, SHARC is built to streamline development under ISO 26262: from capturing requirements and system architecture, through safety analysis, to verifying that the implementation meets safety goals. It leverages model-based development as the backbone for this integration, which we will explore next.

At the heart of SHARC lies a model-based philosophy. Instead of treating hardware design, software design, and safety analysis as separate silos, everything begins with a unified system model. SHARC uses UML (Unified Modeling Language) with the MARTE profile (Modeling and Analysis of Real-Time and Embedded systems) to capture the system design. Let’s break down what that means and why it’s useful:

• UML as a System Blueprint: UML provides a standardized way to describe system structure and behavior using diagrams (like block diagrams, state machines, sequence diagrams, etc.). For an automotive embedded system, UML can represent electronic control units (ECUs), sensors, actuators, networks, and their interactions. By using UML, SHARC ensures that the design is documented in a clear, formal manner that both humans and tools can interpret.
• MARTE Profile for Embedded Systems: MARTE is an extension of UML specifically for real-time and embedded systems modeling. It introduces stereotypes and attributes that let engineers model hardware details and timing characteristics. For example, using MARTE you can denote that a component is a <<HwProcessor>> with a certain clock speed, or a <<HwBus>> with given throughput, or specify real-time constraints. This is crucial for automotive systems where timing (meeting deadlines) and hardware resource constraints must be understood early.
• Hardware/Software Co-modeling: With UML/MARTE, one can describe not only the software logic (like control algorithms in UML activity diagrams or state machines) but also the hardware platform (microcontrollers, communication buses, sensors) that will execute that software. SHARC encourages creating a combined model that covers both domains. This way, the impact of hardware architecture on software and vice versa can be evaluated from the start. For example, you might model two redundant temperature sensors (for safety) feeding into an ECU, and also model the ECU’s internal redundancy (perhaps dual-core lockstep processors) if applicable.
• IP-XACT Integration: Recognizing that UML/MARTE alone might not capture every low-level hardware detail, SHARC incorporates IP-XACT concepts in the modeling. IP-XACT is a standard for describing electronic components (register maps, bus interfaces, etc.) in a machine-readable way. In SHARC, a designer can attach IP-XACT metadata to UML hardware components – like vendor and version information (VLNV), memory maps, or interface specifications. This enriches the model so that it contains everything needed to later generate a hardware prototype or simulation automatically. Essentially, UML/MARTE gives the high-level view and IP-XACT fills in detailed specs.
• From Abstract to Detailed – Stepwise Refinement: One powerful aspect of using UML models is that you can start with a high-level, abstract design and gradually refine it to more concrete detail. SHARC supports this refinement process. In early phases, you might leave certain things abstract (e.g., represent a sensor generically). As development progresses or more information becomes available, that model element can be refined – for instance, replaced with a specific sensor component with concrete parameters. Throughout this refinement, the model remains the central source of truth. Because of this, consistency is maintained – if a requirement changes, you update the model once, and all downstream artifacts (code, simulations, analyses) can be regenerated from the updated model.

Why is this model-based approach beneficial for ISO 26262? It’s because the standard demands rigorous traceability and verification. Every safety requirement needs to be traced to design elements and verified by tests or analysis. When using SHARC’s UML/MARTE model, traceability is easier to manage: you can link safety requirements directly to model elements (say, a hazard mitigation requirement linked to the design of a dual-sensor). Moreover, by having a single model drive the process, you greatly reduce the risk of inconsistencies that often plague projects (like the hardware schematic not matching the safety analysis document, or the test assumptions not matching the design). With SHARC, everyone – system engineers, hardware designers, safety analysts, verification engineers – refers to the same model, each perhaps viewing different aspects, but ultimately synchronized.

Next, we’ll see how SHARC uses this system model to actually perform simulation and verification, starting with Virtual Prototyping.

Building a physical prototype of an automotive ECU or system can be time-consuming and expensive. Virtual Prototyping (VP) addresses this by creating an executable software model of the system that can run much earlier than physical hardware is available. SHARC embraces virtual prototyping to enable early experimentation and testing, and extends it with a concept called SaVeSoC (Safety-aware Virtual Prototype evaluation and verification of a System on Chip).

Here’s how SHARC leverages virtual prototyping:

SystemC/TLM Models: SHARC uses simulation models written in SystemC (and SystemC AMS for analog/mixed-signal parts) to represent the behavior of hardware components. SystemC is a C++ library that allows modeling of hardware at various levels, including the Transaction Level Modeling (TLM) which is often used for fast simulation of systems. For instance, instead of a cycle-accurate model of a microcontroller, a TLM model might simulate the processing time of tasks without toggling every gate signal, greatly speeding up simulation. SHARC comes with a library of such models (sometimes called the System Component Library). This library includes generic models for processors, memories, buses, analog sensors, actuators, etc. Because these models exist, when the engineer builds the UML/MARTE model of the system, they can link each UML component to a ready-to-use simulation model from the library.

Automatic VP Generation: Once the system architecture is modeled (and possibly after performing some safety analyses on it, which we’ll cover later), SHARC can automatically generate a virtual prototype from that model. Essentially, the tool reads the UML/MARTE description of hardware components and connections, and then produces a SystemC representation (using templates or a generator like OVP iGen from the Open Virtual Platforms standard). The result is an executable simulation of the hardware platform. For example, if your model includes an ARM-based microcontroller, a CAN bus, and sensors, the generation process will produce a SystemC program where an ARM core model, CAN bus model, and sensor models are instantiated and interconnected as specified.

Execution of Software on VP: A virtual prototype’s purpose is not just to simulate hardware in isolation, but to run the actual embedded software in a controlled environment. The SHARC framework supports loading firmware or control software onto the processor models in the VP. This means you can start testing your control algorithms and software logic before real hardware exists. If the BMS (Battery Management System) software, for example, is ready, you could run it on the VP of the BMS hardware and see how it behaves.

Safety-Aware Virtual Prototyping (SaVeSoC): What makes SHARC’s approach safety-aware? SaVeSoC augments the virtual prototype with the capability to evaluate safety behavior. In practice, this means two things:

• Fault Injection and Simulation: The virtual prototype environment allows injection of faults into the simulation to mimic hardware failures or extreme conditions. For instance, you can simulate a sensor giving a faulty reading, a bit-flip in memory, or a broken communication link. By injecting such faults in a controlled way, engineers can observe how the system responds – does the safety mechanism kick in? Is the fault detected and mitigated? This is invaluable for verifying that the design meets the safety requirements (which often assume certain faults will be handled). Instead of waiting for hardware testing or worse, an incident in the field, you can test fault scenarios in silico.
• Built-in Monitoring of Safety Metrics: The SaVeSoC framework can monitor events relevant to safety during simulation. For example, it can track if a fault propagated to a hazardous situation without being controlled (which would relate to single-point faults in ISO 26262 terms). By running many simulations with various faults, you can gather evidence about the Single Point Fault Metric (SPFM) and Latent Fault Metric (LFM) for the design. SPFM represents the percentage of single failures that are detected or controlled (ISO 26262 mandates SPFM above 97% or 99% for high ASILs), and LFM similarly for multiple-point failures. SaVeSoC’s ability to simulate and measure these give an early indication if the design’s architecture is robust enough. Additionally, by integrating known component failure rates and using fault trees, the simulation results can help estimate the Probabilistic Metric for random Hardware Failures (PMHF), essentially the failure rate per hour – which for ASIL D needs to be below a threshold (on the order of 10^(-8) per hour).

Integration with Functional Models: Importantly, SHARC doesn’t treat the VP as an isolated artifact. Instead, once the virtual prototype (especially of hardware components) is generated, SHARC integrates it back into the overall system model context. In practical terms, you might have a high-level functional model (say, using MATLAB/Simulink or a high-level UML behavior for the system) and you replace parts of it with the detailed VP for the hardware. This allows a mix-and-match simulation: parts of the system are detailed (running actual software on a CPU model) while other parts may still be abstract. This integration helps verify interfaces and functional correctness: for example, ensuring that the software running on the VP correctly communicates with other system components in the model (like other ECUs or a plant model representing the physical world). It’s a way to gradually refine the system: start with everything abstract and gradually swap in real implementations and test each time.

By employing virtual prototyping early, SHARC helps teams validate design decisions at a stage where changes are much cheaper. If a problem is found (say the CPU chosen isn’t powerful enough, or the fault handling strategy doesn’t meet timing requirements), it’s far easier to adjust the model and regenerate a new prototype than it would be to re-spin a hardware design or rewrite a bunch of code after physical testing. In the next section, we’ll look at how formal safety analysis methods are incorporated alongside this simulation-centric approach.

Compliance with ISO 26262 requires more than just testing the design; it also involves rigorous safety analysis to show that the design can meet safety goals even under faults. Two cornerstone analysis techniques are FMEA (Failure Mode and Effects Analysis) and FTA (Fault Tree Analysis), and the standard also mandates certain hardware architectural metrics as mentioned (SPFM, LFM, PMHF). SHARC supports integrating these analyses directly on the system model, which is a game-changer for efficiency and consistency.

Here’s how SHARC deals with safety analysis and metrics:

• Failure Mode and Effects Analysis (FMEA): In a typical FMEA, engineers list potential failure modes of each component, their immediate effects, and the end effects on the system (including detection and mitigation measures). With SHARC’s model-based approach, a lot of this information can be derived or at least organized systematically. Each component in the UML model can be annotated with its possible failure modes (for example, a sensor might have failure modes like “stuck at high value” or “noise out of range”). The connections in the model help trace the effect: if sensor reading is faulty, what downstream component receives that data and what could happen? SHARC can assist by propagating a failure through the model to see its effects on system-level behaviors. This semi-automated FMEA ensures that no component is overlooked (since all are in the model) and that the effects are traced according to the actual system connections, preventing human error in assumptions.
• Fault Tree Analysis (FTA): Fault trees start from a potential hazard (top-level undesired event) and work backwards to find possible causes (and combinations of causes) that could lead to that hazard. Using the system model, SHARC can help construct fault trees by identifying redundant paths, dependencies, and failure propagation paths. For example, consider a hazard “Battery thermal runaway not detected” in a BMS. The model knows there are two temperature sensors and a microcontroller reading them. SHARC could help generate a fault tree where one branch might be “Sensor 1 fails and Sensor 2 fails (both undetected) leads to hazard” or “Microcontroller fault leads to hazard”. By mapping model elements to fault tree elements, you maintain consistency – if the design changes (say you add a third sensor), the model-based analysis can quickly be updated to reflect a new fault tree structure with that sensor’s failures included. Moreover, SHARC can quantify fault tree leaves if reliability data is provided (like sensor failure rates), yielding quantitative estimates for top event probability, which ties into PMHF.
• Hardware Architectural Metrics (SPFM, LFM): ISO 26262 Part 5 defines target metrics for how much of the hardware failures must be caught by safety mechanisms. SPFM (Single Point Fault Metric) is essentially the percentage of single-point failures (a failure that by itself can cause a hazard) that are covered (i.e., do not lead to the hazard because of safety measures). LFM (Latent Fault Metric) similarly addresses multiple-point faults that are latent (not immediately detected). For high ASILs, the standard sets high bars (for example, ASIL D requires SPFM ≥ 99% and LFM ≥ 90%). Calculating these metrics manually can be very involved, especially for complex architectures. SHARC simplifies this by using the system model and potentially the fault injection simulations to compute the metrics. For instance, after identifying all single failure modes in the model (via FMEA), you can count how many are mitigated (the model includes detection or redundancy for them) versus how many would lead straight to a hazard. Because the model is exhaustive of the system’s components, it can ensure all relevant faults are considered. Additionally, SHARC’s simulation can validate assumptions: if a fault is supposed to be detected by a watchdog, one can inject that fault in the VP and confirm the watchdog catches it. If it doesn’t, that’s a sign the design or the FMEA assumptions need revision. This kind of cross-verification between analysis and simulation is a powerful way to achieve validation of safety mechanisms.
• Probabilistic Metric for Hardware Failure (PMHF): This metric is essentially the probability of a safety-critical failure per hour of operation, aggregated across all possible random hardware faults. Usually, fault tree analysis (with component failure rates) is used to estimate PMHF. By linking to the model, SHARC can help automatically roll up the PMHF from the components. For example, each hardware component in the model could carry a failure rate (from reliability libraries). The model knows if a single failure leads to a hazard or if a combination is needed. With that knowledge, an automated calculation can sum up the contributions in a logical way (taking into account independent or common cause failures). This saves a huge amount of manual calculation and ensures the PMHF is always in sync with the current design. If a component is changed to a more reliable one, the PMHF can be recalculated instantly.
• Design Iteration with Feedback: Perhaps the greatest benefit of integrating FMEA/FTA and metric evaluation into the SHARC workflow is the immediate feedback loop. If analyses show that targets aren’t met – say the SPFM came out too low because a single sensor failure could be catastrophic – the designers can address it right in the model. They might decide to add a second sensor or an error-checking mechanism, update the UML model with that change, and then re-run the analyses and simulation. Within the same environment, they can see if the SPFM now meets the requirement and if the simulated fault injection shows the hazard is prevented. This beats discovering such a gap during a late design review or test, which would require scrambling to add hardware changes or redesign the system under time pressure.

By blending these analytical safety techniques with the design model, SHARC ensures safety is built into the design from the beginning rather than tacked on afterwards. It makes satisfying ISO 26262’s requirements much more systematic. To illustrate how all these pieces come together in practice, let’s walk through a concrete example: developing a Battery Management System.

Consider an automotive Battery Management System (BMS) – a critical component in electric vehicles that monitors and manages the rechargeable battery pack. The BMS is responsible for safety functions like preventing overcharge/over-discharge, avoiding overheating, and balancing cells. Because a failure in the BMS could lead to a battery fire or vehicle shutdown, it must comply with functional safety requirements (often an ASIL C or D system due to the severity of potential hazards). We’ll see how using SHARC can streamline the development of a safe BMS.

1. System Modeling with UML/MARTE: Using SHARC, engineers start by modeling the BMS at the system level. The BMS doesn’t exist in isolation; it interacts with the battery pack and other vehicle systems:

• They create UML structure diagrams showing the battery pack (as a component with perhaps multiple battery cell units), the BMS electronics (which might include a microcontroller, analog front-end for measurements, thermal sensors, etc.), and connections to an inverter or powertrain control unit (which uses the BMS data).
• MARTE stereotypes detail the hardware: for example, the microcontroller is annotated with its type and performance, the sensors with their analog characteristics, and the CAN or LIN bus interface for communication to other ECUs.
• The safety requirements (like “Prevent overtemperature conditions from causing fire”) are linked to this model. Perhaps in a SysML requirements diagram or directly as comments, the team notes which parts of the design address which safety goals.

2. Safety Analysis at Concept Stage: Before diving into implementation, they perform safety analysis on this model:

• A Hazard Analysis might have identified, say, “Thermal runaway in battery undetected” as a top hazard. For that, a safety goal is defined: “BMS must detect over-temperature conditions and take action before cells reach dangerous temperatures” with ASIL D. From this, a technical safety requirement could be “At least two independent temperature sensing channels shall monitor the battery pack temperature” to avoid single point failure.
• Using SHARC’s integrated FMEA tool, the engineers list failure modes: e.g., Temperature Sensor 1 fails low (always reads cool), Temperature Sensor 2 fails low, Microcontroller ADC input stuck, etc. The model allows them to propagate each failure mode: if Sensor 1 fails low but Sensor 2 is still working, the BMS would still detect overheating via Sensor 2 (so that failure is covered by redundancy). However, if both sensors fail, the hazard might occur. They identify that scenario as needing mitigation or being an extremely unlikely double fault.
• They also create a fault tree for “Failure to detect over-temp.” The fault tree shows that both sensors would have to fail or the MCU would have to misread both for the hazard to happen. They check that the design as modeled indeed has two sensors on different ADC channels, and a comparator in software that will trigger an alarm if one sensor disagrees with the other (a plausibility check).
• At this point, if any analysis revealed a weakness (for instance, if both sensors go through the same connector that could come loose – a single point of failure in wiring), the team would catch it now and alter the design (maybe route them differently or add a diagnostic to detect a disconnected sensor).

3. Virtual Prototype Creation: Next, the team uses SHARC to generate a virtual prototype of the BMS hardware platform:

• The UML/MARTE model, now refined with details (a specific microcontroller type, specific sensor model, etc.), is fed into the generator. SHARC produces a SystemC TLM simulation of the BMS hardware. Let’s say it includes an ARM Cortex-M CPU model (to run BMS firmware), a model of the ADC and sensors (perhaps using SystemC AMS to simulate the analog behavior of temperature readings), and the battery pack model (which could be an analog electrical model of a Li-ion cell network that can simulate temperature rise, voltage, state of charge, etc.).
• The BMS software (which reads temperatures, calculates state-of-charge, controls charging, etc.) is compiled and loaded into this VP. Now, we effectively have a virtual BMS: it’s the BMS “in a computer” with its own virtual battery to monitor.

4. Early Simulation and Testing: With the BMS VP ready, the team can perform a host of tests even before any physical BMS hardware is built:

• They simulate normal operation: e.g., charge the battery in the simulation and see how the BMS responds as cells fill up, or simulate a drive cycle where the battery discharges. This helps verify basic functionality (does the BMS correctly report state of charge, balance the cells, etc.).
• Critically, they also perform fault injection tests using SaVeSoC capabilities. For example, they inject a fault where Temperature Sensor 1 suddenly reads 20°C cooler than actual. In the simulation, the battery pack model might be heating up, so the actual temperature reaches a dangerous threshold but sensor 1 is “stuck” low. The BMS software, however, has Sensor 2 reading correctly high. The simulation checks: does the BMS recognize the discrepancy? Perhaps the plausibility check flags that sensors differ by more than 5°C and triggers an error. The BMS should then go into a safe state (maybe send a message to shut down the charger and flag a sensor fault). The engineers observe this in the simulation logs or outputs.
• They repeat such tests systematically: Sensor 2 fault alone, both sensors faulty (to see what happens – ideally that scenario might be recognized as implausible as well or flagged by some other mechanism). They might simulate an ADC calibration error, or a fault in the microcontroller’s logic (maybe by flipping a bit in memory that affects the calculation, if they have such capability).
• All these tests are derived from the safety requirements. In fact, SHARC can help auto-generate some test cases. For each safety requirement, a corresponding test scenario can be defined. For example, requirement “Two sensors for over-temp” translates to test “verify system reacts properly if one sensor fails”. SHARC’s integration with UVM (discussed soon) and constraints allows a variety of random but constrained scenarios to be tested, such as random failure times or different starting conditions, to ensure the BMS safety features work under all conditions.

5. Results and Iteration: Suppose one of the tests uncovered an issue – maybe when both sensors fail together, the system didn’t notice (because that was a double fault scenario beyond the design). Given the severity, the team might decide to add a simple estimator that uses battery current and voltage to infer if heat is likely, as a backup plausibility check. They update the model to include this extra diagnostic feature. With SHARC, they regenerate the prototype, run the analyses again (the fault tree now includes this new path, perhaps reducing the probability of undetected overheating) and re-run simulations. If all tests pass and analysis shows metrics like SPFM and LFM are within required limits, they proceed confidently.

By the end of this virtual development stage with SHARC, the BMS design has been through a gauntlet of verification equal to what many projects would only do on hardware prototypes. The model is verified, the code has been executed in simulation, and evidence for functional safety compliance is already collected (like FMEA reports, coverage of safety requirements by tests, etc.). This means when actual hardware is built and real-world testing begins, there are far fewer surprises. The team can focus on calibration and final validation, rather than discovering fundamental design bugs.

This BMS example highlights the value of SHARC: even a complex, safety-critical system can be designed and checked thoroughly in a virtual environment aligned with ISO 26262 activities. Next, we consider how SHARC promotes reusability and smooth verification flows, which also contributed to speeding up our BMS development in the example.

In automotive projects, efficiency and consistency are greatly improved by reusing components and test assets across the development lifecycle and even across different projects. SHARC is built to facilitate this reuse and to maintain a seamless flow from early design simulations to final system validation. Let’s unpack what this means:

• Reusable Component Library: SHARC’s System Component Library (containing models for processors, sensors, interfaces, etc.) is a treasure trove for design reuse. If your organization has, for example, a reliable motor control unit model or a validated model of a battery cell from a previous project, these can be included in the library. When starting a new design (like our BMS scenario or another ECU), engineers just drag-and-drop those components into the UML model rather than modeling from scratch. Because these library components are already verified in prior use, using them again comes with high confidence. It’s akin to reusing a proven hardware IP block in chip design – you know its behavior, and you know it meets certain safety criteria, so you can focus on how it integrates into the new system rather than re-qualifying it entirely.
• Layered Abstraction and Refinement: Reuse also happens across abstraction levels. Early in development, a placeholder or abstract component might be used (to allow simulating overall system behavior without detail). Later, that component can be swapped with a more detailed, perhaps previously verified, model. For instance, you might start with a generic “BatteryPackModel_v1” that approximates behavior. After some development, you have a refined model “BatteryPackModel_v2” that includes cell balancing details verified elsewhere. SHARC makes it straightforward to replace the component and rerun the same simulation scenarios. Because the interfaces remain consistent (thanks to modeling standards), the rest of the system doesn’t need changes. This plug-and-play capability encourages teams to build up a library of models over time that can be slotted in as needed to increase fidelity.
• Continuous Verification through the V-Cycle: A hallmark of ISO 26262 is that verification isn’t a one-time event; it happens at multiple stages (unit testing, integration testing, hardware-software integration, system testing, etc.). SHARC supports continuous verification by allowing test scenarios and environments to persist and evolve alongside the design:

– The same test cases used on the virtual prototype at unit or component level can be reapplied at system level testing. For example, a safety requirement test like “detect sensor fault within 1 second” that was first run on the BMS VP in isolation can later be run on the integrated vehicle simulation or even on a hardware-in-the-loop rig with the actual BMS. Because SHARC captured that test in a high-level form (using UVM sequences or as constraints), the test isn’t tied to a specific environment. You simply point it to the new platform (with perhaps minor adaptation) and reuse it. This is much more efficient than writing completely new test scripts for each test environment.

– Test artifacts like automated checkers (or validators) are created from the model/requirements and travel with the design. If the BMS had an assertion “temperature difference between sensors should never exceed X for more than Y seconds”, this can be an automated checker in simulation. That same assertion can later be implemented as a real-time check in the hardware or at least a test in HIL. SHARC’s methodology ensures these checks originate from the requirement and remain consistent.

• Single Source of Truth: Seamless flow is achieved by having the model as the single source of truth that drives all downstream activities. In practical terms, this means when the model updates, you can regenerate the code, update testbench, and analysis results all together. It prevents the common issue of “the design changed, but the test environment didn’t realize it” or vice versa. Everything stays in lockstep.
• Avoiding Tool Chain Breaks: Often in development flows, engineers have to export data from one tool and import into another (for example, export a design to a simulator, or copy requirements into a test harness). Each transfer is a chance for error or misalignment. SHARC minimizes such breaks by providing an Eclipse-based integrated environment where modeling, analysis, and simulation setup are all done. The simulation can be launched from the same environment that designed the system. This not only saves time but also reduces human error. For the team, it feels like one continuous process rather than disjointed steps.
• Feedback Loop and Traceability: When a simulation or test finds a problem, tracing it back to the model element or requirement is straightforward in SHARC. If a particular test fails, the engineer can see which part of the model is related and adjust. Likewise, if a requirement is modified, they can quickly identify which simulations and components are affected and re-verify those. This closed-loop capability ensures verification keeps pace with development changes.

All these aspects of reuse and seamless flow contribute to a faster development cycle and a more reliable outcome. Engineers spend less time on mundane re-testing or re-modeling tasks and more on designing new features and thoroughly validating them. Moreover, by reusing components and tests that are known to be good, confidence in the system grows and the risk of unforeseen issues drops.

In the final sections, we’ll discuss the advanced verification techniques SHARC supports, like cloud-based distributed simulation and UVM, and wrap up by looking at how SHARC addresses the broader challenges of scale and time-to-market in automotive projects.

As automotive systems grow in complexity, the amount of testing required to assure safety grows exponentially. Think about an autonomous driving system with countless scenarios to test, or an electric vehicle system that must be verified across a range of temperatures, loads, and fault conditions. Running all these simulations on a single machine or in serial can be prohibitively slow. SHARC tackles this challenge by adopting cloud-based distributed simulation and modern verification methodologies like UVM (Universal Verification Methodology) to efficiently manage a large volume of tests.

Here’s how SHARC leverages these techniques:

• Parallel Simulation in the Cloud: SHARC’s framework supports executing simulations in a distributed manner, meaning multiple simulation instances can run concurrently on a cluster of computers or cloud servers. Suppose you have 100 different test scenarios to run (different combinations of faults, environmental conditions, driving cycles, etc.). Instead of running them one after the other (which might take days), SHARC can dispatch them to, say, 10 or 20 machines to run in parallel, cutting the wall-clock time dramatically. This is especially useful for Monte Carlo testing or exhaustive combinatorial testing required by safety verification. The framework abstracts the execution environment, so it could be your in-house server farm or a public cloud service – the tests don’t care, they run the same. The benefits are obvious: reduced simulation time (you get results faster), scalable capacity (you can flexibly use more machines when you need to test more), and even cost efficiency (renting cloud servers on demand may be cheaper than maintaining a huge in-house compute cluster that sits idle most of the time).
• Distributed UVM Testing: UVM is a popular verification methodology originating from the semiconductor industry (usually for verifying hardware designs in SystemVerilog). It promotes a structured approach to create testbenches using reusable components like drivers, monitors, scoreboards, and uses constrained-random stimulus generation to hit a wide range of scenarios, combined with coverage metrics to know when you’ve tested enough. SHARC brings the spirit of UVM into the system-level simulation domain (with SystemC and high-level models). Tests in SHARC can be constructed as UVM-like sequences of stimuli. For example, a test might be “randomly vary the battery load and intermittently drop out sensor signals over a 1-hour drive simulation” – this can be described with constraints (like ranges for load current, timing for dropout) and the UVM engine will generate a pseudo-random scenario meeting those constraints. By running many such random tests, you get broad coverage of possible events, including rare corner cases that a deterministic test might miss.
• Automation and Repetition: UVM emphasizes automation – tests are code, not manual procedures, and they check the system’s outputs automatically (via monitors and scoreboards that compare behavior to expected outcomes). In SHARC’s context, this means once you set up a verification environment for, say, the BMS, you can programmatically test thousands of scenarios while the environment self-checks if safety requirements were violated or not. The burden on engineers shifts from performing tests to reviewing results of automatically run tests, which is far more efficient.
• Continuous Integration of Simulation: With cloud and automation, it becomes feasible to integrate simulation-based verification into a continuous integration (CI) pipeline for automotive development. For instance, whenever the model or code is updated, a suite of regression tests can automatically run overnight on the cloud to ensure nothing broke any safety requirement. Early in the morning, engineers get a report. This approach is common in software development; SHARC enables it for system-level safety verification. For a safety manager, this is a dream: evidence of compliance is being gathered continuously and any deviation is caught immediately, not at the end of the project.
• Handling Complexity via Hierarchical Testing: Because SHARC supports hierarchical systems, tests can also be distributed by levels. You might run certain tests on a subsystem level in parallel with other tests on a different subsystem. For example, in a full vehicle model, you could simultaneously test the BMS sub-system, the engine control sub-system, and the ADAS sub-system in separate simulations, each focusing on relevant safety scenarios. Later, you could run an integrated simulation where all come together. This flexibility means the verification effort can be partitioned among teams or compute resources effectively.
• Resource Optimization: Another advantage of cloud-based simulation is optimizing license usage for proprietary simulation tools. If some simulation components require licensed software, running many short simulations in parallel and shutting them down when done can free licenses quickly and allow re-use. This fine-grained control can reduce the total number of licenses needed, which is a cost saving.

By applying distributed simulation and UVM, SHARC addresses the verification scalability problem. It ensures that even if you have thousands of test scenarios to satisfy the thoroughness needed for ASIL D, you can practically execute them within project deadlines. It’s no longer a bottleneck to achieve high coverage. Moreover, the combination of random testing and targeted directed tests provides a high level of confidence in robustness: random tests might uncover unexpected combinations of events, while directed tests ensure all known edge conditions (from the safety analysis) are explicitly verified.

Now that we’ve covered all aspects from modeling to analysis to simulation and verification, let’s step back and look at the big picture: how does SHARC help organizations tackle the challenges of complexity, team coordination, and speed?

The SHARC framework, by virtue of its integrated approach, directly addresses several major challenges in developing automotive embedded systems under the strict requirements of ISO 26262:

• Managing Complexity through Hierarchy: Today’s vehicles are among the most complex systems created by humans. By using hierarchical models and abstraction, SHARC helps engineers manage this complexity. Each subsystem can be developed and verified with a degree of independence, yet remain consistent with the overall system model. This hierarchical approach means you can focus on one piece of the puzzle at a time (for instance, just the BMS or just the braking system), and then ensure it fits into the whole. It prevents the project from becoming overwhelming and reduces mistakes that happen when trying to juggle all details at once. Furthermore, hierarchical modeling naturally allows scaling up to larger systems: you can add new subsystems as needed without breaking the existing model, because they interface at well-defined points.
• Closing Organizational Gaps: In many organizations, different disciplines use different languages – system engineers might use MBSE tools, hardware engineers use HDL and simulation tools, software engineers use code and maybe MATLAB, and safety engineers use spreadsheets or specialized safety tools. SHARC creates a common platform where these disciplines meet. The safety engineer can annotate the same UML model that the hardware engineer is refining. The verification engineer’s testbench is generated from the same requirements that the system engineer entered. This shared-source-of-truth approach breaks down communication barriers. Each team still performs their specialty, but they do it in a coordinated fashion. For a functional safety manager, this is a huge benefit: it means less chasing people for updates and less risk that the hardware team changed something that invalidates the safety case unbeknownst to the safety team. Everyone sees the implications of changes immediately through the tool.
• Faster Iteration and Reduced Rework: Time-to-market is critical in the automotive industry, as technology is evolving rapidly and competition is high. SHARC shortens development cycles by catching issues early and by supporting quick iterations. If a requirement changes or a new finding emerges (for example, a new regulation or a test result from a prototype), the team can update the model and regenerate analyses and prototypes in days or hours, rather than weeks. Early simulation results also reduce the number of physical prototype iterations needed. Potentially, a team might skip an entire prototype generation because the virtual testing was sufficient to move to a more final design. Less rework means hitting launch deadlines with confidence.
• Reliability and Quality Improvement: By enforcing consistency and thorough verification, SHARC leads to higher quality outcomes. Designs are more robust because they’ve been vetted against a wide array of scenarios. The risk of a late discovery (like “Oops, this fault wasn’t considered and now our hardware has a flaw”) is vastly reduced. That also means projects have less risk of costly recalls or safety issues in the field, which not only is important for time-to-market but also for a company’s reputation and avoiding legal issues.
• Documentation and Compliance Evidence: Meeting ISO 26262 is not just doing the right activities; it’s also about documentation – showing the auditors that you did your due diligence. SHARC can automatically produce a lot of the documentation needed for compliance: e.g., the FMEA tables, the fault trees, the verification results linked to requirements (proving each safety requirement was tested and passed). By having this generated from the tool, engineers save a ton of time preparing review materials. More importantly, the evidence is trustworthy because it’s directly from the model and tests – there’s less chance of human error in compiling reports. Projects can thus sail through safety assessments more smoothly, again saving time and avoiding last-minute scrambles.
• Alignment with Modern Development Practices: The auto industry is increasingly adopting agile and model-based approaches, moving away from the siloed waterfall processes of old. SHARC fits well with this modern mindset. It enables continuous development and integration of safety, something that was historically very waterfall-like (safety was often only fully addressed at the end when everything came together, which was risky). With SHARC, safety is integral at every sprint or iteration: the model and safety analysis evolve together, and tests are continuously run. This agility in a safety context can be a competitive advantage, allowing companies to innovate rapidly while still being safe.

In summary, SHARC helps organizations build a bridge between high-level safety concepts and low-level implementation details, ensuring that nothing vital falls through the cracks in between. It also erects a fast track on that bridge – meaning you can move from concept to tested design much faster than before. Especially for startups or new EV companies that need to catch up with established OEMs, such acceleration can be critical.