{[ promptMessage ]}

Bookmark it

{[ promptMessage ]}

Session_06 - UT D CS 6386 Telecommunications Software...

Info iconThis preview shows page 1. Sign up to view the full content.

View Full Document Right Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: UT D CS 6386 Telecommunications Software Design Session 06 Embedded, Real-time & Distributed RealSystems Credits: Some slides are from W. Stallings Outline Characteristics of Telecom software systems Embedded systems Real-time systems Distributed systems 2 1 Telecommunications Systems Characteristics Many telecom equipments are embedded systems e.g. PCS handsets Most telecom systems are real-time systems real have time constraints, e.g. dial-tone dial- Most telecom systems are implemented as distributed systems to achieve scalability for capacity and performance for enhanced reliability and availability 3 Embedded Systems Form Factors 4 2 Embedded Systems Definition "A generalgeneral-purpose definition of embedded systems is that they are devices used to control, monitor or assist the operation of equipment, machinery or plant" "Embedded" reflects the fact that they are an integral part of the system. In many cases their embedded-ness embeddedmay be such that their presence is far from obvious to the casual observer and even the more technically skilled might need to examine the operation of a piece of equipment for some time before being able to conclude that an embedded control system was involved in its functioning. At the other extreme a generalgeneralpurpose computer may be used to control the operation of a large complex processing plant, and its presence 5 will be obvious Embedded Systems vs. General Purpose Computers General Purpose Computers Flexible and end-user programmable end Runs thousands of different programs Designed to run multiple applications Designed with concern for performance and speed Performance is an important design factor 6 3 Embedded Systems vs. General Purpose Computers Embedded systems NOT end-user programmable end Designed to run one or a few applications Applications are typically known at design time Usually associated with a microcontroller Operates with fixed run-time constraints run Major design concerns are power consumption and cost 7 Microcontrollers An integrated chip which includes all or most of the parts needed for the controller CPU, RAM, ROM-PROM-EPROM, I/O ports ROM-PROM(serial and parallel), timers, interrupt controller Integration boosts performance and/or cuts costs "Embedded" inside of some other device often a consumer product 8 4 Microcontrollers Characteristics Dedicated usually to one task runs a specific program, usually stored as firmware in read only storage device (ROM/PROM/EPROM) Cost is relatively low only including features specific to the control task Often low-power consumption low Typically processing power is not important Has dedicated input ports takes input from the devices it's controlling 9 The Importance of Low Power Consumption Lower power consumption lower heat dissipation heat sinks are not necessary end result: lower cost and smaller size Power consumption also impacts the portable energy source battery lower power consumption leads to longer battery life smaller volume requirement for battery Reducing power consumption impacts performance 10 5 Embedded Systems? 11 An Operating Systems with the necessary features to support real-time applications real What is a real-time application? realapplication? An application whose correctness depends not only on the correctness of the results from logical computation, but also on the result delivery time An application that responds in a timely, predictable way to unpredictable inputs or events These events occur in "real-time" and application must be "realable to keep up with them Events can be periodic or aperiodic What is a Real-time OS Real(RTOS)? Most telecom systems use RTOS 12 6 Type of Real-Time RealApplications Hard Real-Time Real Missing a deadline (delivery time) has catastrophic results for the system Firm Real-Time Real Missing a deadline causes an unacceptable quality reduction for the application 13 Types of Real-Time Systems Real Soft Real-Time Real Deadlines may be missed and can be recovered from, but application's quality may be reduced Reduction in application quality is acceptable Non Real-Time Real Result delivery has no time constraints The value of a real-time application`s realresults decreases as time goes by 14 7 RealReal-Time Systems Examples Process control plants Air traffic control Vehicle on-board systems onRobotics Entertainment Telecommunications systems 15 Characteristics of Real-Time RealOperating Systems Typically interrupt-driven interrupt Deterministic timing requirements operations are typically performed at fixed, predetermined times or within predetermined time intervals concerned with how long the operating system delays before acknowledging an interrupt 16 8 Characteristics of Real-Time RealOperating Systems Responsiveness the timing of a response is very important how long it takes the operating system to service the interrupt includes amount of time to begin execution of the interrupt service routine includes the amount of time to perform the interrupt service routine 17 Characteristics of Real-Time RealOperating Systems More user control on how a process is managed is typically demanded specify paging what processes must always reside in main memory rights of processes 18 9 Characteristics of Real-Time RealOperating Systems Reliability degradation of performance may have catastrophic consequences most critical, high priority tasks must execute 19 Features Required for RealRealTime Operating Systems Fast context switch To provide quick multiprogramming Small memory size Embedded Ability to respond to external interrupts quickly Responsiveness Multitasking with inter-process communication intertools queues and mailboxes 20 10 Example of Issues in RTOSs Memory Allocation Static memory allocation All memory allocated to each process at system startup Expensive Desirable solution for Hard-RT systems Hard- Dynamic memory allocation Memory requests are made at runtime Should know what to do upon allocation failure Some RTOSs support a timeout function 21 RTOS Memory Allocation HardHard-RT Allocation Scheme Virtual Memory Compaction/Coded Static No No Soft-RT SoftNon-RT Non- Dynamic Dynamic /Static No Yes No Yes 22 11 RTOS Examples VxWorks and QNX VxWorks Multitasking Process-task based ProcessInterruptInterrupt-driven, priority-based prioritytask scheduling, round-robin round256 priority levels (0-255); 0 (0highest, 255 lowest May be set dynamically May be set dynamically Semaphores InterInter-process Communications Counting, binary, mutual-exclusion mutual(recursive), and POSIX, timeouts Message queues (priority or FIFO), pipes, sockets, signals, RPCs Memory based Messages (copied), queues (FIFO), pipes, sockets, signals, proxies 23 QNX ProcessProcess-thread based PriorityPriority-based, round-robin, roundFIFO (cooperative), adaptive (decaying) 32 priority levels (0-31); 0 (0lowest, 31 highest Distributed Systems A distributed system consists of a number of communicating processors working together to perform a common task Distributed processing type Functional distribution Load sharing Distributed vs. multiprocessor systems 24 Shared Memory Multiprocessor Message Passing Multiprocessor Wide area Distributed System 12 Why Distributed Processing? To increase system capacity, performance and availability An analogy term project Work harder Work smarter Work together (team) In processing systems Faster processing engine (processor) More efficient and smarter algorithms Use multiple engines (multiprocessor and distributed systems) 25 Other Drivers for Distributed Processing Enhanced availability and reliability Design of fault-tolerant systems is much easier with faultdistributed processing Scalability Just add more (processing units)! Exploit cheap and readily available hardware COTS (Commercial On-The-Shelf) economies of scale On-The- Advent of faster and faster networking technologies 10 Mbps, 100 Mbps, 1G Mbps, HIPPI etc... Divide-and-conquer Divide-and- 26 13 Functional Distributed Processing Client Server Computing Processing is broken into two parts: user and provider Both are connected and communicating via a network 27 Client Server Architecture Client sends a request to a server Server responds by processing the request and sends back results 28 14 Example of Client Server Applications Web server Clients (browsers) share web pages stored on the web server via intranets or the Internet Application server Applications run on a high performance machine and the machine is shared among clients File server Allows shared access to a larger and more reliable file system 29 HostHost-based Client/Server Processing Nearly all of the processing is done on the host server machine Dump client, e.g. a dumb terminal 30 15 ServerServer-based Client/Server Processing Most processing is done on the server Client provides only an interface e.g. X-window graphic systems X- Client Server 31 Cooperative Client/Server Processing Processing on Client and server Optimized to client and server Examples include Database servers Internet access Client Server 32 16 ClientClient-based Client/Server Processing More processing on the client side Server provides data Client Server 33 Information Caching Consistency of Data Communications overhead can be large Frequently used information are usually cached locally to reduce communications overhead Issue: keeping the information consistent across all machines in the system 34 17 Middleware: Making Distributed Processing Easier Middleware is a layer of software that sits between a communication protocol layer (e.g. TCP) and applications e.g. dRuby, CORBA, DCOM Make communications layers transparent to applications Takes the concept of layering to another level Hides the details of interfacing to the communications layer Allows communication amongst applications with different underlying communication architectures 35 Middleware Layering 36 18 Middleware Logical View 37 Middleware Example 38 19 Middleware Implementation Message Oriented uses message passing mechanism as the means for exchanging information Remote Procedure Call (RPC) Services provided by remote systems are abstracted as function calls Object Request Broker Object oriented middleware Publish Subscribe Producer/Consumer type 39 Message Oriented Middleware Client sends a message to a local queue Middleware passes the message through transport layer and on to the server Server replies with the result contained in messages Middleware sends result messages to the client 40 20 Message Passing Basic Primitives 41 Message Passing Reliability vs. Unreliability Reliable message-passing guarantees messagedelivery if possible Not necessary to let the sending process know that the message was delivered Send the message out into the communication network without reporting success or failure Reduces complexity and overhead 42 21 Message Passing Blocking vs. Nonblocking Nonblocking Process is not suspended as a result of issuing a Send or Receive Efficient and flexible Difficult to debug Blocking Send does not return control to the sending process until the message has been transmitted, or does not return control until an acknowledgment is received Receive does not return until a message has been 43 placed in the allocated buffer RPC - Remote Procedure Call Middleware Processing occurs on remote machine but transparent to applications Simple mechanism can be used as the basis for other middleware schemes Stub program interfaces to applications 44 22 RPC Implementation Stub program makes RPC appear similar to local function call Quiz: What aspects of computing that are different in RPC (vs. local function call) and must be addressed? 45 Differences between Local and Remote Procedure Calls Main difference Caller and callee are on the same processor RPC happens across two processors Different data representation Size and format of data, byte ordering Pointers loose their meaning Must pass by value Data marshalling addresses the issue Client packs data into a common format, server unpacks data into its own format 46 23 Object Request Broker Middleware Clients can invoke methods on objects that exist anywhere in the system Local to the machine or across the network Similar to RPC, but object oriented A client does not know where the object resides The middleware takes care of the interface 47 Middleware CORBA Common Object Request Broker Architecture An implementation of object request broker middleware The ORB knows where services are A server must register with the ORB A client requests a reference to the server object An Interface Definition Language (IDL) is used to describe interface of each object IDL generates skeleton code on each end This code handles differences between platforms 48 24 CORBA Implementation Client sends a request to the client ORB The ORB finds the requested service Sends to server ORB if needed Communication across the underlying network is done using the internet inter-ORB protocol (IIOP) inter Result is returned to the client 49 PublishPublish-Subscribe Middleware Number of producers on a network Each producer generates a different type of data Consumers may subscribe to different producers New data is broadcasted to subscribed consumers 50 25 Multiprocessor Systems Shared Memory Computing systems where two or more CPUs share a common main memory Tightly-coupled multiprocessor systems Tightly- Access to main memory Uniform (UMA) (UMA) every memory operation takes the same amount of time Non-uniform (NUMA) Non(NUMA) access time varies due to caching, different access mechanism, etc... 51 Multiprocessor Communications Bus is widely used as communications networks for a multiprocessor not very scalable The processors typically have their own memory, may also have a private cache Shared memory and caching adds problems Synchronization Data coherence Without a Cache With Cache With private cache and memory 52 26 Symmetric Multiprocessor OS Only one copy of the OS in memory Any CPU can run OS system calls Maintain mutual exclusion for OS data structures Resources are dynamically allocated as needed 53 Cluster Computing Nodes (processors) are physically separated and do not share a memory Communications occur across a network Message passing is typically used but shared memory can also be implemented Nodes are typically individually scheduled at the application level Load sharing Single Switch Ring Torus Hypercube 54 27 Major Issues in Telecom Software Systems More design constraints vs. other systems Size, power consumption, etc.... (embedded systems) Time (deadlines) timers are used frequently Real-time requirements exist yet delay is introduced Realdue to sharing information via networks Race conditions Temporal relation among messages are very important to the correctness of applications Synchronization is required Dead-locks Dead Harder to avoid in distributed systems Reliability Stringent performance requirements 55 28 ...
View Full Document

{[ snackBarMessage ]}