The pace of change is picking up in the automotive industry. Three areas of innovation are converging. The first is the trend toward electric vehicles (EVs). The second is the increasing sophistication of advanced driver-assistance systems (ADAS) combined with ever greater levels of autonomy. The third is referred to as the “digital cockpit,” which—broadly speaking—refers to the digital experience within the car, including instrument clusters, multi-screen displays, heads-up displays, advanced navigation systems, infotainment systems, voice assistants and the list goes on.

All of this is leading to the concept of software-defined vehicles (SDVs), whose features and functions are primarily enabled through software with updates and new services being delivered over-the-air (OTA). SDVs offer significant safety and convenience features and enable new in-vehicle experiences and functions.

(more…)

The boundless possibilities of automation in cars and other vehicles have captivated designers to the point that electronic content is now a stronger driver of differentiation than any other factor. It accounts for a substantial fraction of material cost in any of these vehicles. But this revolution in automotive technology comes with a caveat. In other applications, an electronics problem may be corrected with a shutdown or a reboot. The same resolution, however, does not work well for cars. Misbehavior in the electronics can lead to accidents, even fatalities.

To address this real concern, the ISO 26262 standard was crafted to set guidelines for electronics safety in cars. This context details the characterization and measurement during automotive electronics design. One of the most important analyses in the standard is Failure Modes, Effects and Diagnostic Analysis (FMEDA) for each component. It lists potential failure modes with the corresponding impact on the system’s safety and methods to mitigate such failures. These reports communicate safety characterization through the value chain, from IPs to automotive OEMs, as shown in Figure 1.
(more…)

Over the years, Arteris IP has worked with several aerospace, transportation and automotive partners on design systems for avionics, space image processing and processing for scientific payloads. More recently, complex advanced driver-assistance systems (ADAS) projects at various levels of autonomy have been added to the list. One thing common between all these projects has been the tight coupling between system-level specification and all aspects of software and hardware from multiple suppliers and integrators, along with the very tight demands on safety and reliability. All are governed by standards like DO-254, ISO 26262, ECSS-Q80 and others. A common theme in all these standards is the expectation of being able to trace requirements from the system definition to implementation and verification. If a change is made anywhere which invalidates a requirement in this complex web of suppliers and integrators, that problem should be immediately detectable.

Figure 1: Traceability requires linking artifacts and decisions forwards and backwards in time, and at two different
levels: (1) Along the “V” and (2) Across the “V.”

There Is no Escaping Traceability

Although traceability has always been expected in aircraft and spacecraft design, the scope of safety-critical applications has grown beyond the traditional bounds. ISO 26262 requires that safety requirements in the automotive industry must be traceable. Also, IEC 61508 (general electronic safety) and IEC 60601 (medical electrical equipment) require traceability for functional safety. The bottom line, it is getting much harder to avoid traceability requirements.
(more…)

Chip designers build circuits that go into larger systems, often extensive ones such as cars, aircraft, ships, satellites and spacecraft. How are those designed, and how do those constraints interact with the implementation of sub-components, like an embedded system?

For many years, the answer was through the exchange of documents – high-level specifications, requirements and key performance indicators. In 2007, the international council on systems engineering (INCOSE) introduced an initiative called model-based systems engineering (MBSE) to formalize the application of modeling to support all phases of system design, from concept through development and later lifecycle phases. The use of this approach is now common in aerospace development. It is also taking off in automotive design and gaining recognition in large-scale infrastructure projects – public works, utilities, airports and seaports. This means it is increasingly likely that new products are aimed at platforms already using or planning to adopt MBSE.

SysML Modeling, From Systems Design to Component Design

System designers must think about the whole system project – mechanical, environmental, software, electronic components and more. These designs cannot be fully represented in C, mechanical CAD drawings or register-transfer level (RTL) language. Instead, unified modeling language (UML) might be a better choice to use, but that is very software-centric. Another popular option, though, is systems modeling language (SysML). SysML is an extension of a subset of UML for systems engineering that eliminates software-only features and adds support for more general needs, requirements, parametrics and modeling. This is now published as an ISO standard (ISO/IEC 19514:2017) and has become a central component of MBSE.
(more…)

In technology, the only constant is change, sometimes at a dizzying pace. One emerging trend is how product specifications, additions and changes are passed onto system-on-chip (SoC) design teams. Traditionally, this transfer is done by exchanging documents, models (perhaps Simulink) and some form of written use-case descriptions. However, this process is very cumbersome, subjective and error-prone. It is also a very poor method for documenting and tracking revisions required by agile design teams employing best practices. It may not be a problem when building catalog products, but the world has changed. Requirements are now defined much more collaboratively in automotive, aerospace and other domains and enabled by a process called model-based systems engineering (MBSE).

What Is Model-Based Systems Engineering?

Systems engineering is about the total system – an aircraft, spacecraft, airport or seaport, or more recently, a car, truck, and high-speed trains. These systems are architected by teams using many disciplines: mechanical, electrical, software, aerodynamics, thermal, etc. Once each engineering discipline defines the various parameters, each element has a purpose.

(more…)

IP-XACT is a vendor-neutral intellectual property (IP) exchange, configuration and system-on-chip (SoC) assembly standard for portable generator development. The standard is associated with generating a netlist or testing SystemC. It is not widely connected to SoC verification, but this is starting to change because of the proliferation of complex verification IPs (VIPs). IP-XACT simplifies and standardizes building SoC designs around complex IPs. In principle, it could also help develop elaborate SoC testbenches for VIPs.

(more…)