0% found this document useful (0 votes)
80 views54 pages

Unit-3 Rtos Case Study

The document presents several case studies on programming modeling, focusing on digital cameras, adaptive cruise control systems, smart cards, and mobile phone software. Each case study details the hardware and software architecture, class diagrams, and synchronization models relevant to the respective systems. The studies emphasize the integration of various components and the importance of compliance with safety standards in embedded systems.

Uploaded by

Sasi Bhushan
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
80 views54 pages

Unit-3 Rtos Case Study

The document presents several case studies on programming modeling, focusing on digital cameras, adaptive cruise control systems, smart cards, and mobile phone software. Each case study details the hardware and software architecture, class diagrams, and synchronization models relevant to the respective systems. The studies emphasize the integration of various components and the importance of compliance with safety standards in embedded systems.

Uploaded by

Sasi Bhushan
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 54

PROGRAMMING MODELING – CASE

STUDIES

1. Case Study of Digital Camera Hardware and Software Architecture

2. Case Study of Embedded System for an Adaptive Cruise Control (ACC)


System in Car Case Study of Embedded System for a Smart Card

3. Case Study of Embedded System of Mobile Phone


Software for Key Inputs.
CASE STUDY OF DIGITAL CAMERA HARDWARE AND SOFTWARE
ARCHITECTURE
A digital camera is an example of SoC. the camera functions, hardware and software units.
CLASS DIAGRAMS
1. Picture_File Creation is an abstract class from which an extended class(es) is derived to create a JPEG encoded picture. The task objects are instances of the classes

Exposed Area_CCD Bytes Stream, Dark Area_CCD Bytes Stream, Task CCD Preprocessor, Task_Picture Processor and Task_Encoding.

2. Exposed Area_CCD Bytes Stream is to create a byte stream from the ADC outputs from the exposed cells in each row of the picture frame.

3. Dark Area_CCD Bytes Stream is to create a byte stream from the ADC outputs from the unexposed (dark area) cells in each row of the picture frame.

4. Task CCD Preprocessor creates a stream after the subtraction of the average of bytes for each row of bytes in output from DarkArea_CCD BytesStream from the stream for

rows in output of Exposed Area_CCD Bytes Stream.

5. Task_Picture Processor creates a stream after processing the Task_CCD Preprocessor for picture brightness, contrast and color adjustment.

7. Task_Encoding creates Huffman encoding for JPEG encoding and creates a file stream for saving onto internal flash or memory stick. Picture_File Display is an abstract

class which extends three classes Task_Decoding. Task_DisplayProcessor, Task Display.

8. Picture_File Transfer is an abstract class which extends three classes. Task_Printer, Task_USB Port.Task_MemoryStick.

9. Controller Tasks which extends to the following tasks:


 Tasks Initialization for initialization of tasks,
 Tasks Shoot for shooting tasks,
 Initialize_Picture_File Creation to initialize CCD processor (CCDP),
 Initialize_Picture_File Display tasks, which initiates display processor (DispIP), Initiates processor (MemP), Initiates processor PrintP, initiates USB port processor

(USB_P),
 Task_LightLevel for control level control,
 Task_flash. Drawing the class diagram for Controller Tasks is an exercise for the reader.
DIGITAL CAMERA HARDWARE ARCHITECTURE

• System layer System layer provides system services, for example, display text with the picture,
flash start and stop after timeout of an auto timer, saving and retrieving of processor internal
registers, and OS vices such as IPCs (inter-process communication).
• Application layer Application layer is for system switches, button and control tasks. Examples
are flash. light, contrast and image view before shooting.
• Function layer Function layer is for application layer tasks functionality using Picture
FileCreation. Picture_FileDisplay and Picture FileTransfer.
• Presentation layer Presentation layer is for providing standard access to an image file. Examples
are the default settings of image contrast, resolution, outputs, display color setting, sound of clicks.
time and date display, dot-matrix or touchscreen driver, ADC output format and data outputs.
• Control layer Control layer is for Controller_Tasks, timer control and real time control modules.
• Base layer Base layer provides a standard access to the internal devices in the microcontroller.
Internal device examples are timer, real-time clock, SI (serial interface), ADC, and USB port
CASE STUDY OF EMBEDDED SYSTEM FOR n ADAPTIVE CRUISE
CONTROL (ACC) SYSTEM IN CAR
The system has a number of ports for data input and output. The system uses a control algorithm.
• The port devices and their functions are as follows:
1. Port Align: It is a stepper motor port. Motor steps up clockwise or anticlockwise on a signal from task Align. The motor aligns the radar or
UVHF transmitting device in the lane of front-end car.
2. Port ReadRange: It is a front-end car range-measuring port. Time difference deltaT is read on a signal from task Signal to port device. The
port radar emits the signals through the antenna and sensor antenna receives the reflected signal from the front-end car task_ReadRange reads
the Port device circuit for the computations of delay period between the transmission and reception instances. Delay period in s multiplied by
1.5 x 10 m measures the range range Now (= distance d) in km of the front-end car. task_ReadRange sends message for d to task RangeRate
and all other streaming cars.
3. Port Speed: The port control function routine enables free running counter overflow interrupt. On receiving a signal from task Speed, the port
device reads a free running counter count on first one-bit input from the wheel and also sets a parameter N_rotation = 0. The counts are saved
in a memory buffer allotted for the port data. Each successive wheel rotation causes port to note the countN at this instance, where countN is
the count on Nth rotation. Also N_rotation increments by I each time countN saves. The port control function routine disables when free
running counter overflows. After the counter overflows, it finds the difference of the last value of countN in the buffer and count). Current
speed v = speedNow = (N_rotation x wheel circumference in m)/ [Telockx (countNcount) x 1000] km/s to task Algorithm.
4. 4. Port Brake: Port device applies the brakes or emergency brakes on an interrupt signal. The service routine ISR Brake Control disables the
interrupts at the beginning and enables on exiting the critical section. It applies the brakes and signals this information to all the other
streaming cars also.
CLASS DIAGRAM
ACC HARDWARE ARCHITECTURE
• A hardware system in automotive electronics has to provide functional safety. Important hardware
standards and guidance at present are the following:
(a) TTP (Time Triggered Protocol)
(b) CAN (Controller Area Network)
(c) MOST (Media Oriented System Transport)
(d) IEE (Institute of Electrical Engineers) guidance standard exists for EMC.
An automotive embedded system-based control unit uses microcontroller and separate
microprocessor or DSP. ACC embeds the following hardware units:
1. A microcontroller runs the service routines and tasks except task_Algorithm. Microcontroller
has the internal RAM/ROM. RAM stores temporary variables and stack. ROM/Flash saves the
application codes and RTOS codes for scheduling the tasks. CAN port interfaces with the CAN
bus at the car. The CAN interfaces ACC system with the other embedded systems of the car.
Interrupt controller at microcontroller control the interrupts.
2. A separate processor with RAM and ROM for the task Algorithm executes the adaptive control
algorithm.
An automotive embedded system-based control unit uses microcontroller and separate microprocessor or DSP. ACC embeds the following hardware

units:

1. A microcontroller runs the service routines and tasks except task_Algorithm. Microcontroller has the internal RAM/ROM. RAM stores

temporary variables and stack. ROM/Flash saves the application codes and RTOS codes for scheduling the tasks. CAN port interfaces with the

CAN bus at the car. The CAN interfaces ACC system with the other embedded systems of the car. Interrupt controller at microcontroller

control the interrupts.

2. A separate processor with RAM and ROM for the task Algorithm executes the adaptive control algorithm.

3. Speedometer

4. Stepper motor-based alignment unit.

5. Stepper motor-based throttle control unit.

6. Transceiver for transmitting pulses through an antenna hidden under the plastic plates.

7. LCD dot matrix display controller, display panel with buttons.

8. Port devices are Port_Align, Port Speed, Port_ReadRange, Port Throttle and Port Brake. These five port devices are used for five actions as

follows: aligning transmitted beam toward the lane, measuring speed v, range d at the ACC, throttle positioning (as per the control messages

fro task Algorithm) and braking action (as per messages fro ISR_BrakeControl).
ACC SOFTWARE TASKS SYNCHRONIZATION MODEL
The units, tasks of ACC system, cycle of actions and synchronizing cycle of different units. ACC system cycle of actions and task scheduling model. Note

the marks 1 to 10 of cycle starting and finishing in the figure.

1. Cycle starts from a task, task Align on an event (ISR call). It sends the signal to a stepper motor port Port_Align and Port_Ranging. The stepper

motor moves by one step clockwise or anticlockwise as directed.

2. A task task ReadRange is for measuring front-end car range. The task disables all interrupts as it is entering a critical section. We need real-time

measurement. Port ReadRange finds d.

3. task Speed gets the port reading at a port Port_Speed. Task sends v, using the count and count) interval between the initial and Nth rotation.

4. Task_Range Rate sends the range Now. It estimates the final error in maintaining the string stability from task_ReadRange output. It estimates of

the error for maintaining the car speed from the task Speed output. It outputs both error values for use by the control system adaptive algorithm.

Port_Speed connects to the speedometer system of the DAS, which displays speedNow after appropriate filtering function. Port_Range Rate

transmits the speedNow also to other streaming cars also. Now Task calculates range and rate errors, and transmits both range Now and speed Now.

5. task_Algorithm runs the main adaptive algorithm. It inputs are as follows. It gets inputs from task_ RangeRate. The task outputs are events to Port

Throttle and brake. Port Throttle attaches to the vacuum actuator stepper motor. After a delay, the cycle again starts from the task Align. It reads the

statuses of Port_Brake of this and other streaming cars.


ACC SOFTWARE IMPLEMENTATION

ACC software for use in automobiles must first be certified by an organization authorized to issue
that certification. OSEK OS standard is required .
 Only those VxWorks or MUCOS functions that adhere to OSEK must be used.
Software coding IEC 61508 part 3 and MISRA C version 2 (2004) specifications of safety
standards and coding language must be used. [MISRA stands for Motor Industry Reliability
Association.]
MISRA C specifies a collection of rules to be used while coding in C MISRA-C is a standard for C
language software and defines the guidelines for automotive systems.
CASE STUDY OF AN EMBEDDED SYSTEM FOR A SMART CARD

REQUIREMENTS
Assume a contact-less smart card for bank transactions.
Let it not be magnetic. [The earlier card used a magnetic strip to hold the non volatile memory.
Nowadays, it is EEPROM or flash that is used to hold nonvolatile application data] Requirements
of smart card communication system with a host can be understood through a requirement.
CLASS DIAGRAM

A cycle of actions and card-host synchronization in the card leads us to the model Task Card
Communication for system tasks.
Card system communicates to host for identifying host and authenticating itself to the host.
ISRI_Port_IO. ISR2_Port_I0and ISR3_Port_10 are interfaces to the tasks. [A class gives the
implementation methods of the interfacing routines.]
The task_Appl. task_PW. task_ReadPort, and resetTask are the objects of Task_Appl.
Task_PW.Task_ReadPort and Task Reset, respectively. These classes are extended classes of
abstract classTask_CardCommunication.
HARDWARE AND SOFTWARE ARCHITECTURE
 JVM has thread scheduler built in. No separate multitasking OS is thus needed when using Java because all Java byte codes

run in JVM environment.


 Java provides the features to support (1) security using class java.lang. Security Manager), (ii) cryptographic needs (package

java.security). Java provides support to connections, datagrams, 10 streams and network sockets.
 Java mix is a new technology in which the native applications of the card run in Cor C++ and downloadable applications run

in Java or Java Card™, The system has OS and JVM both.SmartOS is an assumed hypothetical OS in this example, as RTOS

in the card. Remember that a similar OS function name is used for understanding purposes identical to MUCOS but actual

SmartOS has to be different from MUCOS.


 Its file structure is different. It has two functions as follows: The function unsigned char [1 SmartOSEncrypt (unsigned char

"applStr, EnType type) encrypts as per encryption method, EnType = "RSA" or "DES" algorithm chosen and returns the

encrypted string. The function unsigned char || SmartOSDecrypt (unsigned char *Str, DeType type) encrypts as per

deciphering method, DeType = "RSA" or "DES" algorithm chosen and returns the deciphered string. SmartOSEncrypt and

SmartOSDecrypt execute after verifying the access conditions from the data files that store the keys, PINs and password.
SYCHRONIZATION MODEL

Following are the actions on the card placed near the host machine antenna in a machine slot.
• Step 1: Receive from the host, on card insertion, the radiation of carrier frequency or clock signals
in case of contact with the card. Extract charge for the system power supply for the modem,
processor, memories and Port_IO (card's UART port) device.
• Step 2: Execute codes for a boot up task on reset resetTask.The codes begin to execute from the
main and the main creates and initiates this ask and starts the SmartOS. There it is the resetTask,
which executes first.
CASE STUDY OF A MOBILE PHONE SOFTWARE FOR KEY INPUTS

Mobile phones are smart.Each phone has many APIs. Example of APIs are phone, SMS, MMS, e-
mail, address book, web browsing, calendar, task-to-do Itst. WordPad, Pocket-Word, Pocket-
Excel, note-pad for memos, Pocket-PPTs, slide show and camera.
Mobile phone with a large touchscreen uses a virtual keypad. Mobile phone with a small screen
uses T9key pad.
The present case study relates to 'SMS create application in a mobile phone with T9 keypad for
inputs.
REQUIREMENTS
 A processor, keypad, screen, scratch pad memory, persistence memory and communication units are required for SMS

create and send application.


 Scratch pad memory addresses are used for temporary saving of characters tes during the application.
 Persistence memory addresses are used such that as soon a change is made in the byte, it persists even after the power

switches off.
 The screen is used for Displaying. there are four cursor keys (up, down, left and right) denoted by CI. C2, C3, and C4. In

computer keyboard, four different cursor keys are used.


 The mobile cursor key in the keypad is such that it functions as four keys. When the key is pressed towards the left the

cursor moves left (-), when it is pressed towards the right the cursor moves right (→), and so on for up (↑) or down (4).
 In addition there are four command keys (right-corner second-row, left-corner second-row, right-corner first-row and

left-corner fust-row) denoted by key2Row2, key 1 Row2, key2Rowl and key 1 Row 1.
 Also, there are nine T9 keys for numbers 1 to 9 as well as for alphabets a to z (or A to Z). There are two mode-keys

(keyM1 and keyM2) and one keys key keying in a text character number 0 or space. Alphanumeric text in small case or
capital case is controlled by a mode-key's state. Text character entered on keying depends on state of the T9 key
CLASS DIAGRAM AND CLASSES

• Assume that SMS creation application consists of three class diagrams for Orchestrator and two for
Task_SMS_CreateTextSend and Task Screen Displ.
1. ORCHESTRATOR class extends to Orchestrator CommandsGUIs and to Orchestrator_SMSCreate
Send.
2. Task_Messages. Task_TextMessages, Task_Create Message and Task_Text and interface
keypadinterrupt ISR_KINT.
3. Task_SMS_CreateTextSend extends to Task_AddNumber, Task_AddEmail. Task_AddList. Task
EditMessage, Task_ListRecipient and Task_Send.
4. Four types of screen displays are used during SMS create and send application. Start up screen display,
menu items display, SMS display during editing task and action display during sending the SMS. Task
Screen Displ thus extends to four classes Task StartUpDispl. Task_SMSDispl. Task_ActionDispl and
Task Menu TextLines Displ.
5. The ISRs are ISR_WirelessPort, ISR_T_Out_Help_Option. ISR_T_Deacitvate and ISR_KINT.
6. ISR_KINT runs the service functions for any of the state transitions of twenty key and senates
notifications for the state of a key Key1 Rowl or Key1 Row2 or. Key2Row1, Key2Row2, CI to C4, M1
or M2 or keys 0 to 9.lass Figure 12.22 shows Task_Menu .
STATE DIAGRAM

• A state diagram shows a model of a structure for its start, end, in-between associations through the
transitions and shows events-labels (or conditions) with associated transitions.
• A dark rectangular mark within a circle shows the end. The state transitions take place between the
tasks, task_SMS-CreateTextSend and task_AddNumber, task_AddEmail, task AddList. task
EditMessage, task ListRecipient and task Send.
• A state transition occurs after notification of MsgAddNumber, MsgAddEmail, MsgAddList,
MsgEditMessage, MsgListRecipient and MsgSend on selection of menultems Add Number. Add
Email. Add List, Edit Message, List Recipient and Send, respectively.
• Task Send posts the event to initiate ISR_Wireless Ports through Orchestrator to send SMS and
end the application.
SMS KEYING HARDWARE

• Hardware architecture specifies the appropriate decomposition of hardware into processors.


• ASIPs, keys, memory, ports and devices It also specifies interfacing and mapping of these
components. Specifications for SMS keying-in hardware are as follows:
Cursor key One four-way cursor key, which is pressed to move the cursor up, down or left or right
of character when editing the SMS when it is being created. The actions are similar to 1, 1, and keys
in a keyboard. On cursor-key interrupt on click, the notifications are sent for the states Cikey. C2key.
Cakey and C4key and current cursor display-position.
Command keys Four number command keys, key1row 1, key2row 2, key1row2 and key2row 2 are
present. Use of KeylRowl and Key2Row1is similar to the left and right clicks in a computer-mouse
for GUIs.
Key-system layer: A layer in software architecture is used for the key-system.
• A key click generates an interrupt and a service routine ISR KINT, which then executes a:
Orchestrator.
• The ISR_KINT reads the port status bits to find which key has been clicked, and also to read the
timer status and timer counts and cursor position and that position menu or text message.
• It signals the Orchestrator to initiate and generates the notifications and events and posts these into
the message boxes and event boxes for waiting tasks.
SOFTWARE TASKS AND SYNCHRONIZATION MODEL
• The SMS communication system has a cycle of actions and tasks synchronizing model. Orchestrator posts notifications to thetask
Messages, task TextMessages, task CreateMessage and task Text
1. A cycle starts in Orchestrator. A task, task Messages, which receives a notification by messageS_Key IRowl choice of command. It
posts MsgMessages
2. A task task_TextMessages is for command option. It posts message MsgTextMessages on user selection. Another task
task_CreateMessage accepts MsgTextMessages and posts MsgCreate on user selection. Another task task_Text accepts MsgCreate and
posts MsgText on user selection.
3. Orchestrator then posts E_SMS. On receiving E_SMS the Task_SMS_CreateTextSend signals the displaying of menu items for
initiating task_AddNumber, task_EditMessage and task_Send, task AddEmail and task_ListRecipient.
4. Task task_AddNumber adds the message mobile number for sending the SMS in a list. It posts message MsgAddNumber on user
selection.
5. On user selection, Orchestrator posts message, which signals another task task_EditMessage to start. It is used for creating and editing
the message by keying-in the characters. Orchestrator accepts state of key on each key click and posts state in the message box of the
key clicked during the editing. Task_EditMessage accepts state message of the keys and creates the SMS_Create_Text string.
6. On user selection. Orchestrator posts message, which signals another task task Send.
7. Task_Send posts MsgSend. Orchestrator accepts MsgSend and posts MsgCommuncation for Communication Port Interface. It accepts
MsgCommuncation and posts SMS_Create_Text string through wireless.

You might also like