EE4673/5673 - Embedded Systems

Assignment Module #2

Problem 1
Describe at least three advantages of a centralized embedded system over a distributed
embedded system. Also, describe at least three disadvantages of a centralized embedded
system over a distributed embedded system.
Problem 2 (writing assignment part 1)
Read the paper Recent Advances in In-vehicle embedded systems (on my site) and write
a one-page summary including your own opinion of the material presented in the paper.
Problem 3 (writing assignment part 2)
Read the paper Embedded systems overhaul (on my site) and write a one-page
summary including your own opinion of the material presented in the paper.

Seth Waddingham
EE5673 Mod 2 HW
6 September 2014
Problem 1
Describe at least three advantages of a centralized embedded system over a distributed
embedded system. Also, describe at least three disadvantages of a centralized embedded
system over a distributed embedded system.
Advantages
1. One of the first major advantages to using a centralized computer comes from
the fact that a designer is allowed to choose where they place that centralized
computer. From an EMI perspective, this can be beneficial because the
designer can place the central computer in a location that is shielded from
noise and outside interference, thus increasing the reliability of the system.
2. Another major advantage is that software only needs to be written for one
device, as opposed to writing software for several different distributed
controllers. As a result, the software will tend to be more straight-forward
since the designer doesnt have to focus as much energy on ensuring proper
hand-shaking between distributed devices.
3. The only major advantage is that the designer can select a single, powerful
CPU that can be used for this centralized device. Along with this, as parts
become obsolete or as demands on the central CPU change, the designer can
easily switch the CPU to a device that works better for the current application.
Disadvantages
1. The first disadvantage comes from the fact that distributed networks have
greater composability. This means that in a distributed network the
combination of subsystems is going to work correctly and not require the need
for redesigns. Additionally, individual systems can be certified individually
and it isnt require to recertify the entire system as a whole.
2. Another disadvantage is that central CPU systems may not be easily scalable.
If the central CPU is already at its limits and the system needs to be expanded,
it requires a near entire redesign of the system to accommodate the new CPU.
3. Finally distributed systems are much more dependable. If a central CPU fails
the entire system fails. In a distributed network, if one portion fails you lose
that feature but the entire system as a whole will still have some use.

Seth Waddingham
EE5673 Mod 2 HW, Problem 2
6 September 2014
The issues addressed in the article Recent Advances in In-vehicle Embedded Systems
are in regard to the growing complexity that is being found in the embedded systems
found within our everyday automobiles. As newer technologies are developed, it has
become the expectation and the demand of the customer to have these newer technologies
working effectively within their own vehicles. The problem arises from the fact that there
is no industry standard at this point for incorporating all of these various embedded
systems that are to be installed in modern automobiles.
If automobile manufacturers are going to incorporate all of the desired systems and
technologies demanded by consumers then new standards and methods need to be
developed in order to make it cost effective for automobile manufacturers to design and
incorporate these systems into automobiles. There are several proposed solutions to this
issue, many of which lie in the software used within the ECUs inside of an automobile.
The other solutions include utilizing multi-core ECUs, which is the most widely used
protocol currently in the industry while the other various standards are being finalized.
The first system improvement for embedded systems involves the software that is being
used to install onto an ECU. There are 3 major protocols being worked at this moment
known as AIL_transport, EAST-ADL, and EAST-ADL2. The main purpose of these
various protocols comes from the fact that we need a special way to handle the safety
critical functions within an automobile if we are going to safely replace those systems
with electrical systems, as opposed to using mechanical ones. EAST-ADL is domain
specific and utilizes constructs such as classes and attributes. Additionally it can be used
to describe the dependencies between the structural aspects of automotive elements.
The industry standard that is working the hardest to solve all of these future challenges in
the automobile industry is the AUTOSAR protocol. AUTOSOR is a standard software
architecture for automobiles. The aim of AUTOSAR is to provide suppliers software
standards for developing ECU software to reduce cost, improve transferability, and to
improve upon implementation times for the various systems. To tackle the integration
issues in AUTOSAR, a hierarchical scheduling framework is being providing server
technology to fix the problem. The idea is to dedicate part of the CPU to this server so
that there is never a concern about safety critical items not being relayed to the ECU.
The most widely used solution at this point in the industry involves multicore ECUs.
Multicore ECUs are also an attractive solution due to their parallel nature of solving and
computing data and tasks. The drawback is the complexity of the design required to
ensure that designs are computed properly in parallel. However multicore ECUs allow
the ability to perform computations of several different systems at one time. The
challenge comes from the need to ensure CPUs are properly allocating resources due to
the nature of computing several things at one instance.

My understanding from this article is although there are several proposed solutions for
how to streamline the software development process in automobiles, there is no real great
solution at this point in time. I like the general idea behind AUTOSAR, which is to create
standard software protocols for various automobile subsystems. The issue is that I feel
that this should be a company policy to reduce cost, not an industry standard.
I dont know of too many suppliers who would be willing to develop their software the
exactly same way as their competitors. Also if the software is designed to run a certain
way, that means the hardware would have to be very similar in almost every application.
This standard essentially makes every supplier the same, which is obviously very
appealing to automobile manufacturers, but very damaging to companies that supply
electronics to the automobile industry.

Seth Waddingham
EE5673 Mod 2 HW, Problem 3
6 September 2014
Similar to the previous article, Embedded Systems Overhaul is discussing the
challenges that exist in the automobile industry in regard to improving embedded system
development with increasingly complex automobiles. As newer technologies are
developed, it has become the expectation and the demand of the customer to have these
newer technologies working effectively within their own vehicles. The problem arises
from the fact that there is no industry standard at this point for incorporating all of these
various embedded systems that are to be installed in modern automobiles.
This particular articles focuses on correcting the challenges in the automobile industry by
implementing the AUTOSAR standard. The AUTOSAR standard is a protocol developed
to provide industry wide standards for embedded software development for various
automobile systems such as braking and engine control. The idea behind AUTOSAR is
that if a standard design exists for embedded implementation amongst suppliers than it
will be easier for automobile manufacturers to receive supplier equipment because there
will be a standard for how they developed it.
The other suggestion made by this article is to design hardware around the software, as
opposed to the other way around. The logic here being that rather than being constrained
by hardware and having to change software based on the available parts, a software
developer can write their code in a standard way and then its the responsibility of the
hardware engineer to design his circuits around what the software developer created.
I have several issues with the suggestions being made in this article, and frankly with the
overall goal of the AUTOSAR standard. To create a software standard for suppliers
essentially eliminates the competition amongst the suppliers. Anyone who has ever
designed software knows that there arent infinite hardware combinations that result from
that software. There is typically one optimal hardware configuration for each optimal
software configuration. Therefore if a standard software configuration is created, that
likely means the hardware used in each case is likely going to be the same. That makes
every single supplier develop each product for the automobile in nearly an identical
fashion.
If every supplier creates their modules the same way then that eliminates a lot of the
competition because automobile manufacturers will simply go to the supplier than can
offer the product for the cheapest cost, which will go to the larger suppliers than can
afford to make up the profits from their other divisions. A lack of competition is bad for
everybody, including the auto manufacturers. I would hope that with AUTOSAR that
something has been created to prevent this type of behavior from occurring.