Individual software components, each
representing a function or a subset thereof, must be developed and verified
before they can be delivered to the more advanced simulation stages. The SWC
that emerges from this step is proven to adhere to the AUTOSAR interface
specification, including its ports and OEM interfaces.
While the SWC is the smallest discrete
component that can be manipulated as a unit within the ECU, the SWC itself is
in turn made up of code elements known as “Runnables.”
The Tier 1 supplier’s task is to
implement the desired behavior; that is, to make the SWC live up to the design
intent. Either manual coding or automatic code generation can be used to
achieve this result.
The input for the ECU simulation
normally consists of the extracted ECU configuration which is generated by an
AUTOSAR authoring tool such as Mentor Graphics Volcano™ Vehicle Systems
Architect (VSA). The ECU configuration contains all of the information items
assigned to a specific ECU. This includes the ECU software composition that
describes the overall functional behavior of the ECU. Depending on the desired configuration,
this will involve simulation starting with an initial high level of abstraction
(for software architecture validation) and proceeding down to detailed
In this phase, all software components
are assembled into the top-level composition. The simulation in this step
addresses the software architecture and the overall behavior of the logic
architecture. By this means the interaction of software components coming from diverse
suppliers can be “virtually” integrated and verified.
Consistency checks and design rule checks
In contrast to the dynamic
simulations just summarized, consistency checks are static analyses applied at
key points in each phase of the design flow.
Consistency checks begin early in
the development process. In a consistency check, a design’s compliance with its
specified parameters is monitored, as are the design rules that apply.
Consistency checks can also
verify name conventions as well as the validity and completeness of parameters.
A typical consistency check might be expressed as follows:
connection X not valid because of the incompatible data
elements of the connected sender/receiver interfaces”
DRCs (Design Rule Checks) are
usually design-specific and user-defined. A DRC literally monitors adherence to
recorded rules such as:
X must be available twice on the control unit Y to ensure redundancy”
To execute DRCs a tool must be
equipped with an open interface that allows user-specific rules to be
formulated according to a rule description language such as OCL (Object
Constraints Language). A prerequisite for DRC checking is, of course, access to
all objects, parameters, and relationships defined in the AUTOSAR meta-model.
Double-click reveals errors’ hidden causes
A dedicated "Problems
View" in the AUTOSAR Authoring Tool VSA (Vehicle Systems Architect) displays
the result of a series of consistency checks. Double-clicking on an error
message causes the cursor to jump directly to the cause of the problem in the
AUTOSAR Editor, allowing the cause of the problem to be spotted easily.
A consistent design forms the
basic prerequisite for a simulation, because the quality of the input
parameters ultimately determines the feasibility and quality of the simulation.
The number of the parameters to be specified depends largely on the abstraction
level to be simulated. AUTOSAR defines two abstraction levels:
·The Virtual Function Bus (VFB) and…
·The Runtime Environment (RTE)
These two abstraction levels form
the foundation for AUTOSAR simulations that will be performed subsequently.
illustrates the VFB level. The Virtual Function Bus defined by AUTOSAR is a
representation of the communication management among SWCs. The data exchange
between the SWCs takes place via data elements, based on the sender/receiver or
client/server communication. It must be noted here that within the VFB level, no
communication passes to the Basic Software (BSW) layer, which is hierarchically
below the RTE. This has been defined deliberately to ensure a clear separation
between hardware and software, and it provides an abstraction to a purely
functional presentation. The timing is determined by the time constants of the
RTE Events that trigger the executables. The VFB abstraction level is an
efficient means to verify the functional behavior of the software architecture
early in the development process, which helps the engineer detect and correct
design problems early, when the cost of doing so is lowest.
David Patterson, known for his pioneering research that led to RAID, clusters and more, is part of a team at UC Berkeley that recently made its RISC-V processor architecture an open source hardware offering. We talk with Patterson and one of his colleagues behind the effort about the opportunities they see, what new kinds of designs they hope to enable and what it means for today’s commercial processor giants such as Intel, ARM and Imagination Technologies.