1 / 8

Real Time specialization

Real Time specialization. OOSE does not bind the solution space of RT applications at the beginning Abstract model of real-time systems (9.1)

kare
Download Presentation

Real Time specialization

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Real Time specialization • OOSE does not bind the solution space of RT applications at the beginning • Abstract model of real-time systems (9.1) • Sensors and actuators provide respectively a view of the applications behavior in the external environment and a means of controlling the external environments behavior • resource structure include HW and SW • process - structural and behavioral unit

  2. Classification of RT systems • Hard (Aircraft system) … failure to meet deadlines lead to catastrophe • non-hard (telephone) • types of application processes • critical - deadlines must be met • essential - missing deadlines does not lead to catastrophe • non essential • periodic • aperiodic • In hard systems, deterministic predictability of processes’ execution is an essential property. We must guarantee processing of all critical and aperiodic processes • In non-hard RT systems, quality and performance is measured in terms of service provided

  3. Fundamental Issues • 3 fundamental issues • the view of processes • the means of communication • the method of synchronization • strong semantics provided at the behavioral level radically affect the resource structure. If semantic gap exists between the behavioral description and the implementation environment, typically long-lasting complexities are built into the solution (affecting maintainability, extendibility, and reliability) • OOSE does not provide strong semantics to address means of communication and synchronization issues • It is essential to retain strong logical coupling between the application problem and the actual implementation environment to achieve traceability (otherwise it will be very difficult to test the system)

  4. Analysis • The use cases provided in analysis provide a strong tool to capture real-time requirements • Attach both hard (control process to be completed in 100 ms for maneuvering the plane) and non-hard (ability to handle 20000 subscribers) requirements at this stage • Time attributes may be related to both periodic (e.g., frequency) and aperiodic (max response time) processes. • Concurrency requirements, both within and between use cases can be included in analysis. It may involve many instances of a use case. • During construction, the analysis structure may be modified to accommodate RT requirements.

  5. RT requirements often come from the externals of the system. The sensors and actuators of the system are then often tightly connected to these requirements. • Fig 9.2 shows the use of interface objects to interact with the external system. Alternatively, one can design the sensors and the hardware as internal to the system as an entity object (e.g., temperature gauge), and read values from it using one of its methods.

  6. Construction • RT systems are often based on process concurrency in the target environment • Behaviors in the use cases are mapped on to the individual concurrent processes • Fig 9.3., shows that processes are orthogonal to objects, i.e., one process may involve many objects and one object may be involved in many processes • There may be 2 threads may use the same instance of block 3 or there may be 2 instances of the object for the two processes • threads or lightweight processes simulate processes with shared memory addresses • it is possible to share an instance between threads, so it is preferred in OO programming • OS should support concurrent processes. The semantics (such as RPC, timeouts etc) from the OS (implementation environment) can then be included in OOSE • Buffering can be used for synchronization. (one process for incoming stimuli and one process for outgoing stimuli). In some cases the OS can handle mutually exclusive atomic processes.

  7. Time critical functions are typical for hard real-time systems. Use cases that involve them must run as separate high-priority processes. • In distributed environment, the principal strategy is to encapsulate the distribution inside a block (Fig. 9.4). • Tightly coupled objects (with large number of stimuli between them) should be kept in one process to avoid OS overhead on communication. • However, if objects are not coupled, do not place them in the same process even if they have the same periodicity. • To handle process communication and synchronization we can introduce intermediate processes (see fig 9.5, 9.6) and handle issues such as deadlock, starvation etc • RT use cases can be described using interaction diagrams (9.7) • To handle concurrency problems we use state transition graphs. In these graphs we can see which stimuli can be received at what times and hence get more fault tolerance

  8. Testing and verification • Extremely difficult for RT systems • Hard deadlines may be met most of the times and make it difficult to test • Processes using common resources may rarely execute simultaneously. Failure can be time dependant and thus difficult to simulate. • systems may behave differently with debugging tools

More Related