CAN( Controller Area Network) BUS:

 The CAN bus was designed for automotive electronics and was first used in production cars in 1991.
 It uses bit-serial transmission.
 CAN runs at rates of 1 MB/s over a twisted pair connection of 40 m.
 An optical link can also be used.
 The bus protocol supports multiple masters on the bus.
Physical Layer:
 As shown in Fig 4.6.1, each node in the CAN bus has its own electrical drivers and receivers that
connect the node to the bus in wired-AND fashion.
 In CAN terminology, a logical 1 on the bus is called recessive and a logical 0 is dominant.
 When all nodes are transmitting 1s, the bus is said to be in the recessive state; when a node transmits a
0, the bus is in the dominant state.
 Data are sent on the network in packets known as data frames.
 CAN is a synchronous bus—all transmitters must send at the same time for bus arbitration to work.

Fig 4.6.1 Physical and electrical organization of a CAN bus

Data frame:
 The format of a CAN data frame is shown in Fig 4.6.2.
 Fig 4.6.2 The CAN data frame format
 A data frame starts with a 1 and ends with a string of seven zeroes.
 The first field in the packet contains the packet’s destination address and is known as the arbitration
field.
 The destination identifier is 11 bits long.
 The trailing remote transmission request (RTR) bit is set to 0 if the data frame is used to request
data from the device specified by the identifier.
 When RTR1, the packet is used to write data to the destination identifier.
 The control field provides an identifier extension and a 4-bit length for the data field with a 1 in
between.
 The data field is from 0 to 64 bytes, depending on the value given in the control field.
 A cyclic redundancy check (CRC) is sent after the data field for error detection.
 The acknowledge field is used to let the identifier signal whether the frame was correctly received:
 The sender puts a recessive bit (1) in the ACK slot of the acknowledge field;
 If the receiver detected an error, it forces the value to a dominant (0) value.
 If the sender sees a 0 on the bus in the ACK slot, it knows that it must retransmit.
 The ACK slot is followed by a single bit delimiter followed by the end-of-frame field.
Arbitration:
 Control of the CAN bus is arbitrated using a technique known as Carrier Sense Multiple Access
with Arbitration on Message Priority (CSMA/AMP).
 Network nodes transmit synchronously, so they all start sending their identifier fields at the same
time.
 When a node hears a dominant bit in the identifier when it tries to send a recessive bit, it stops
transmitting.
 By the end of the arbitration field, only one transmitter will be left.
 The identifier field acts as a priority identifier, with the all-0 identifier having the highest priority.
Remote Frames:
 A remote frame is used to request data from another node.
 The requestor sets the RTR bit to 0 to specify a remote frame; it also specifies zero data bits.
 The node specified in the identifier field will respond with a data frame that has the requested value.
 Note that there is no way to send parameters in a remote frame.
Error Handling:
 An error frame can be generated by any node that detects an error on the bus.
 Upon detecting an error, a node interrupts the current transmission with an error frame, which
consists of an error flag field followed by an error delimiter field of 8 recessive bits.
 The error delimiter field allows the bus to return to the quiescent state so that data frame
transmission can resume.
 The bus also supports an overload frame, which is a special error frame sent during the interframe
quiescent period.
 An overload frame signals that a node is overloaded and will not be able to handle the next message.
 The CRC field can be used to check a message’s data field for correctness.
 If a transmitting node does not receive an acknowledgment for a data frame, it should retransmit the
data frame until the frame is acknowledged.
 This action corresponds to the data link layer in the OSI model.
 As shown in fig 4.6.3, the controller implements the physical and data link layers; since CAN is a bus,
it does not need network layer services to establish end-to-end connections.
 The protocol control block is responsible for determining when to send messages, when a message
must be resent due to arbitration losses, and when a message should be received.

Fig 4.6.3 Architecture of a CAN controller

Other Automotive Networks:
 The FlexRay network has been designed as the next generation of system buses for cars.
 FlexRay provides high data rates—up to 10 MB/s—with deterministic communication.
 It is also designed to be fault-tolerant.
 The Local Interconnect Network ( LIN) bus was created to connect components in a small area,
such as a single door.
 The physical medium is a single wire that provides data rates of up to 20 KB/s for up to 16 bus
subscribers.
 All transactions are initiated by the master and responded to by a frame.
 Several buses have come into use for passenger entertainment.
 Bluetooth is becoming the standard mechanism for cars to interact with consumer electronics devices
such as audio players or phones.
 The Media Oriented Systems Transport (MOST) bus was designed for entertainment and
multimedia information.
 The basic MOST bus runs at 24.8 MB/s and is known as MOST 25; 50 and 150 MB/s versions have
also been developed.
 MOST can support up to 64 devices and the network is organized as a ring.
 Data transmission is divided into channels.
 A control channel transfers control and system management data.
 Synchronous channels are used to transmit multimedia data; MOST 25 provides up to 15 audio
channels.
 An asynchronous channel provides high data rates but without the quality-of-service guarantees of
the synchronous channels.

The I2C Bus:

 The I 2C bus is a simple and well-known bus commonly used to link microcontrollers into systems.
 Example for I2C is used for the command interface in an MPEG-2 video chip.
 In this a separate bus was used for high-speed video data and setup information was transmitted to the
on-chip controller through an I2C bus interface.
Physical layer:
 I2C is designed to meet the low cost and easy to implement.
 The data transmission speed is moderate of 100-400 KB/s
 As a result, it uses only two lines:
 Serial Data Line (SDL) for data transmission and
 Serial Clock Line (SCL), which indicates when valid data are on the data line.
 Fig 4.7 shows the basic I2C bus, every node in the network is connected to both SCL and SDL.
 Some nodes may be able to act as bus masters and the bus may have more than one master.
 Other nodes may act as slaves that only respond to requests from masters.

Fig 4.7 Structure of an I2C bus system

Electrical interface:
 Fig 4.7.1 Electrical interface to the I2C bus
 The basic electrical interface to the bus is shown in Fig 4.7.1.
 The bus does not define particular voltages to be used for high or low so that either bipolar or MOS
circuits can be connected to the bus.
 Both bus signals use open collector/open drain circuits.
 A pull-up resistor keeps the default state of the signal high, and transistors are used in each bus
device to pull down the signal when a 0 is to be transmitted.
 Open collector/open drain signaling allows several devices to simultaneously write the bus without
causing electrical damage and also it allows a slave device to drag a clock signal when respective data is
to be read.
 The master is responsible for generating the SCL clock, but the slave can drag the low period of the
clock not the high period.
 The I2C bus is designed as a multi-master bus for several different devices may act as the master.
 A master drives both SCL and SDL when it is sending data.
 When the bus is idle, both SCL and SDL remain high.
 When the SCL and SDL are try to drive two different values, the open collector/open drain circuitry
prevents errors and sending the information status to the masters and slaves.
 If the device receives a different value without error then the transmission is known it is interfering
with another message not the original message.
Data Link Layer:
 Every I2C device has separate address.
 These addresses consist of 7 bits of device address and one bit of read/write data.
 Totally 8 bit of address in extended I2C device allows 10-bit addresses.
 To generate 0000000 is used for 8 bit device to signal all devices simultaneously and for extended 10-
bit device generate call address is 11110XX.
 The format of an address transmission is shown in Fig 4.7.2.

Fig 4.7.2 Format of an I2C addresses transmission.

Fig 4.7.3 State transition graph for an I2C bus master

 A bus transaction comprised a series of 1-byte transmissions and an address followed by one or
more data bytes.
 The transaction is between the master and slave.
 When a master wants to write a slave, it transmits the slave’s address followed by the data.
 Since a slave cannot initiate a transfer, the master must send a read request with the slave’s address
and let the slave transmit the data.
 An address transmission includes the 7-bit address and 1 bit for data direction: 0 for writing from the
master to the slave and 1 for reading from the slave to the master.
 A bus transaction is initiated by a start signal and completed with an end signal as follows:
 A start is signaled by leaving the SCL high and sending a 1 to 0 transition on SDL.
 A stop is signaled by setting the SCL high and sending a 0 to 1 transition on SDL.
 However, starts and stops must be paired.
 A master can write and then read by sending a start after the data transmission, followed by another
address transmission and then more data.
 The Typical bus transaction is shown in Fig 4.7.4.

Fig 4.7.4 typical bus transactions on the I2C bus

 In the first example, the master writes 2 bytes to the addressed slave.
 In the second, the master requests a read from a slave.
 In the third, the master writes 1 byte to the slave, and then sends another start to initiate a read from
the slave.
Byte Format:

Fig 4.7.5 transmitting a byte on the I2C bus

 Fig 4.7.5 shows how a data byte is transmitted on the bus, including start and stop events.
 The transmission starts when SDL is pulled low while SCL remains high.
 After this start condition, the clock line is pulled low to initiate the data transfer.
 At each bit, the clock line goes high while the data line assumes its proper value of 0 or 1.
 An acknowledgment is sent at the end of every 8-bit transmission, whether it is an address or data.
 For acknowledgment, the transmitter does not pull down the SDL, allowing the receiver to set the
SDL to 0 if it properly received the byte.
 After acknowledgment, the SDL goes from low to high while the SCL is high, signaling the stop
condition.
Bus arbitration:
 The bus uses this feature to arbitrate on each message.
 When sending, devices listen to the bus as well.
 If a device is trying to send a logic 1 but hears a logic 0, it immediately stops transmitting and gives
the other sender priority.
 In many cases, arbitration will be completed during the address portion of a transmission, but
arbitration may continue into the data portion.
Application Interface:
 The I2C interface on a microcontroller can be implemented with varying percentages of the
functionality in software and hardware.
 This system has a 1-bit hardware interface with routines for byte level functions.
 The I2C device takes care of generating the clock and data.

Fig 4.7.6 An I2C interface in a microcontroller

 The application code calls routines to send an address, send a data byte, and so on, which then
generates the SCL and SDL, acknowledges, and so forth.
 One of the microcontroller’s timers is used to control the length of bits on the bus.
 Interrupts may be used to recognize bits.
 However, when used in master mode, polled I/O may be acceptable if no other pending tasks can be
performed, since masters initiate their own transfers.
QUALITY ASSURANCE:
 The quality of a product or service can be judged by how well it satisfies its intended function.
 A product can be of low quality for several reasons, such as
 It was shoddily manufactured,
 Its components were improperly designed,
 Its architecture was poorly conceived, and
 The product’s requirements were poorly understood.
 The quality assurance (QA) process is vital for the delivery of a satisfactory system.
Example: The Therac-25 medical imaging system
 In the course of six known accidents, these machines delivered massive radiation overdoses, causing
deaths and serious injuries.
 Leveson and Turner analyzed the Therac-25 system and the causes for these accidents.
 The Therac-25 was controlled by a PDP-11 minicomputer and it was responsible for controlling a
radiation gun that delivered a dose of radiation to the patient.
 It also runs a terminal that presents the main user interface.

Fig 4.5
 The machine’s software was developed by a single programmer in PDP-11 assembly language over
several years.
 The software includes four major components:
 stored data,
 a scheduler,
 a set of tasks, and
 Interrupt services.
 The three major critical tasks in the system follow:
 A treatment monitor controls and monitors the setup and delivery of the treatment in eight phases.
 A servo task controls the radiation gun, machine motions, and so on.
 A housekeeper task takes care of system status interlocks and limit checks.
 Let’s examine the software problems responsible for one series of accidents.
 Treat is the treatment monitor task, divided into eight subroutines (Reset, Datent, and so on).
 Tphase is a variable that controls which of these subroutines is currently executing.
 Treat reschedules itself after the execution of each subroutine.
 The Datent subroutine communicates with the keyboard entry task via the data entry completion flag,
which is a shared variable.
 Datent looks at this flag to determine when it should leave the data entry mode and go to the Setup
test mode.
 The Mode/energy offset variable is a shared variable: The top byte holds offset parameters used by
the
Datent subroutine, and the low-order byte holds mode and energy offset used by the Hand task.
 When the machine is run, the operator is forced to enter the mode and energy, but the operator can
later edit the mode and energy separately.
 The software’s behavior is timing dependent.
 If the keyboard handler sets the completion variable before the operator changes the Mode/energy
data, the Datent task will not detect the change—once Treat leaves Datent, it will not enter that
subroutine again during the treatment.
 However, the Hand task, which runs concurrently, will see the new Mode/energy information.
 Apparently, the software included no checks to detect the incompatible data.
 After the Mode/energy data are set, the software sends parameters to a digital/analog converter and
then calls a Magnet subroutine to set the bending magnets.
 Setting the magnets takes about 8 seconds and a subroutine called Ptime is used to introduce a time
delay.
 Due to the way that Datent, Magnet, and Ptime are written, it is possible that changes to the
parameters made by the user can be shown on the screen but will not be sensed by Datent.
 One accident occurred when the operator initially entered Mode/energy, went to the command line,
changed Mode/energy, and returned to the command line within 8 s.
 The error therefore depended on the typing speed of the operator.
 Leveson and Turner emphasize that the following poor design methodologies and flawed
architectures were at the root of the particular bugs that led to the accidents:
 The designers performed a very limited safety analysis.
 Mechanical backups were not used to check the operation of the machine.
 Programmers created overly complex programs based on unreliable coding styles.
QUALITY ASSURANCE TECHNIQUES:
 The International Standards Organization (ISO) has created a set of quality standards known as
ISO 9000.
 ISO 9000 was created to apply to a broad range of industries, including but not limited to embedded
hardware and software.
 The processes used to satisfy ISO 9000 affect the entire organization as well as the individual steps
taken during design and manufacturing.
 We can, however, make the following observations about quality management based on ISO 9000:
Process is crucial:
 Knowing what steps are to be followed to create a high quality product is essential to ensuring that all
the necessary steps are in fact followed.
Documentation is important:
 The creation of the documents describing processes helps those involved understand the processes
 Documentation helps internal quality monitoring groups to ensure that the required processes are
actually being followed and
 It also helps outside groups to understand the processes and how they are being implemented.
Communication is important:
 Quality ultimately relies on people.
 Good documentation is an aid for helping people to understand the total quality process.
 The people in the organization should understand not only their specific tasks but also how their
jobs can affect overall system quality.
 Metrics are used in quality control process to know the levels of quality, the execution speed of
programs or the coverage of test patterns and the rate at which bugs are found.
Role of ISO 9000:
 To help organizations to study their total process, not just particular segments that may appear to be
important at a particular time.
 One well-known way of measuring the quality of an organization’s software development process is
the
Capability Maturity Model (CMM).
 The CMM provides a model for judging an organization.
 It defines the following five levels of maturity:
1. Initial: A poorly organized process, with very few well-defined processes.Success of a
project depends on the efforts of individuals, not the organization itself.
2. Repeatable: This level provides basic tracking mechanisms that allow management to
understand cost, scheduling, and how well the systems under development meet their goals.
3. Defined: The management and engineering processes are documented and standardized.
All projects make use of documented and approved standard methods.
4. Managed: This phase makes detailed measurements of the development process and product
quality.
5. Optimizing: At the highest level, feedback from detailed measurements isused to
continually improve the organization’s processes.
VERIFYING THE SPECIFICATION:
 Verifying the requirements and specification is very important for the simple reason that bugs in the
requirements or specification can be extremely expensive to fix later on.
 Fig 4.5.1 shows how the cost of fixing bugs grows over the course of the design process.

Fig 4.5.1 Long-lived bugs are more expensive to fix

 The longer a bug survives in the system, the more expensive it will be to fix.
 A coding bug, if not found until after system deployment, will cost money to recall and reprogram
existing systems, among other things.
 Discovering bugs early is crucial because it prevents bugs from being released to customers,
minimizes design costs, and reduces design time.
Requirements Validation:
 Prototypes are a very useful tool when dealing with end users—rather than simply describe the
system to them in broad.
 It will not be fully functional since the design work has not yet been done.
 It can help the end user critique numerous functional and non-functional requirements, such as data
displays, speed of operation, size, weight, and so forth.
 Certain programming languages, sometimes called prototyping languages or specification
languages, are especially well suited to prototyping.
 Very high-level languages (such as Mat lab in the signal processing domain) may be able to perform
functional attributes, but not non-functional attributes such as the speed of execution.
 Preexisting systems can also be used to help the end user articulate his or her needs.
 In some cases, it may be possible to construct a prototype of the new system from the preexisting
system.
Validation of Specifications:
 Building prototypes, specification languages, and comparisons to preexisting systems are as useful to
system analysis and designers as they are to end users.
 Auditing tools may be useful in verifying consistency, completeness, and so forth.
 Working through usage scenarios often helps designers fill out the details of a specification and
ensure its completeness and correctness.
 In some cases, formal techniques (that is, design techniques that make use of mathematical proofs)
may be useful.
 Proofs may be done either manually or automatically.
 Automated proofs are particularly useful in certain types of complex systems.
DESIGN REVIEWS:
 It is a simple, low-cost way to catch bugs early in the design process.
 A design review is simply a meeting in which team members discuss a design, reviewing how a
component of the system works.
 Some bugs are caught simply by preparing for the meeting, as the designer is forced to think through
the design in detail.
 Other bugs are caught by people attending the meeting, who will notice problems that may not be
caught by the unit’s designer.
 By catching bugs early and not allowing them to propagate into the implementation, we reduce the
time required to get a working system.
 We can also use the design review to improve the quality of the implementation and make future
changes easier to implement.
Design Review Format:
 A design review is held to review a particular component of the system.
 A design review team has the following members:
 The designers of the component being reviewed are, of course, central to the design process.
They present their design to the rest of the team for review and analysis.
 The review leader coordinates the pre-meeting activities, the design review itself, and the
post-meeting follow-up.
 The review scribe records the minutes of the meeting so that designers and others know
which problems need to be fixed.
 The review audience studies the component. Audience members will naturally include other
members of the project for which this component is being designed and they add valuable perspective
and they may notice problems that team members have missed.
 The design review process begins before the meeting itself.
 The design team prepares a set of documents (code listings, flowcharts, specifications, etc.) that will
be used to describe the component.
 These documents are distributed to other members of the review team in advance of the meeting, so
that everyone has time to become familiar with the material.
 The review leader coordinates the meeting time, distribution of handouts, and so forth.
 During the meeting, the leader is responsible for ensuring that the meeting runs smoothly, while the
scribe takes notes about what happens.
 The designers are responsible for presenting the component design.
 A top–down presentation often works well, beginning with the requirements and interface
description, followed by the overall structure of the component, the details, and then the testing strategy.
 The audience should look for all types of problems listed below.
 Is the design team’s view of the component’s specification consistent with the overall system
specification, or has the team misinterpreted something?
 Is the interface specification correct?
 Does the component’s internal architecture work well?
 Are there coding errors in the component?
 Is the testing strategy adequate?
 The notes taken by the scribe are used in meeting follow-up.
 The design team should correct bugs and address concerns raised at the meeting.
 While doing so, the team should keep notes describing what they did.
 The design review leader coordinates with the design team, both to make sure that the changes are
made and to distribute the change results to the audience.
 If the changes are straight forward, a written report of them is probably adequate.
 If the errors found during the review caused a major reworking of the component, a new design
review meeting for the new implementation may be useful.