Download
principles of engineering system design n.
Skip this Video
Loading SlideShow in 5 Seconds..
Principles of Engineering System Design PowerPoint Presentation
Download Presentation
Principles of Engineering System Design

Principles of Engineering System Design

213 Views Download Presentation
Download Presentation

Principles of Engineering System Design

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Principles of Engineering System Design Dr T Asokan asok@iitm.ac.in

  2. INTRODUCTION TO SYSTEMS DESIGN Interface Architecture Development Contd….. Dr T Asokan asok@iitm.ac.in

  3. Standards Standards ensure that an interface will enable the connection of two components. Each component is required to meet a given standard, and the interface is designed to meet the same standard. There are many benefits in having standards for interfacing.

  4. Interchangeability • Ability to interchange components with performance/cost characteristics • Interoperability • Ability to operate with a wider variety of external systems • Portability • Ability to run on various systems • Reduces cost and risk • Increased life cycle

  5. Standards have different levels of formality: formal, de jure, and de facto • Formal standards: • Negotiated and promulgated by accredited standard bodies. • ISO, ANSI, IEEE, EIA • De-jure: (mandated by legal authorities) IDEF0 (by FIPS) • De facto: (through popular usage) X windows, OS

  6. Formal Standards: OSI(Open System Interconnection ) Architecture • Introduced for network based communication between end-user nodes in a telecommunications network. • In 1983, ISO and CCITT ( International Telephone and Telegraph Consultative Committee) approved a reference model for OSI • Reference model contains seven layers- physical, data link, network, transport, session, presentation, and application

  7. Communication in the OSI reference model Host node Host node Intermediate node Physical Media

  8. CORBA - Common Request Broker Architecture • A standard that would permit programmers to integrate software modules resident on the same network by treating each application as an object. • Developed in association with industries like HP, HYPERDESK, SUN etc.. • Part of CORBA, interface definition language is a formal standard adopted by ISO. • CORBA is a de jure standard in US • Is a de facto standard in other parts of the world.

  9. IDL is a universal notation for software interfaces defining a boundary between the client code (request for services) and the software objects that implement those services. • Apart from IDL, the four additional categories of objects that comprise the CORBA are ORB (object request broker), CORBA facilities, CORBA services and CORBA domains • ORB is the interface between client and server

  10. Client Server Object Request Broker (ORB) CORBA overlaid on OSI seven layer model

  11. Interface Design Process • I. Define interface requirements: • Identify the items to be transported • Emergency communications from the elevator to the building/emergency response team (ERT) • Define the operational concept • Bound the problem with an external diagram • Define objectives hierarchy • availability of interface, fidelity of communicated message, operational cost, deployment cost. • Write the requirements

  12. Interface Design Process • Select a high level interface architecture of interface • Identify several candidate architectures • Telephone connection, dedicated communication system network to ERT, etc… • Evaluate alternatives against requirements • Dedicated network is too expensive • Choose high level interface architecture: • Telephone connection is chosen

  13. Develop functional architecture of the interface • Functional decomposition • Fault detection and recovery • Develop Physical architecture of interface • Identify candidate architectures • Eliminate infeasible candidates • Develop operational architecture of interface • Analyse behavior and performance • alternatives

  14. Summary • Interfaces are the primary responsibility of System Engineers • Interfaces are the most common failure point on systems. • Standards play a major role in the design or selection of interface

  15. CASE STUDY: PATH FINDER • Path finder system that was deployed to the surface of Mars for a landing on 4th July 1997 was a great success in many ways. • Few days into the mission, operators on the ground noticed that total system resets were occurring that were causing the loss of data. • A shared memory interface was used as the system interface between various sub systems. • A priority system had been established for giving various activities access to this interface. Bus management, lengthy communications by spacecraft, meteorological data etc.. • Mutual exclusion (mutex) locks were employed to give an activity access to the interface.

  16. CASE STUDY: PATH FINDER • Meteorological data was so voluminous that the activity had to obtain and release mutexes several times before it was finished. • The long running, medium priority, communication activity would infrequently interrupt the meteorological activity during its pause and gain control of the interface.

  17. Duration of these two tasks were sufficiently long to invoke a watchdog timer that was employed to ensure that the high priority bus management task was executing appropriately. • In such rare cases, watch dog timer initiated a total system reset to prevent any further damage to the system. • Jet Propulsion Lab. Engineers ran a pathfinder replica on earth till they reached the reset situation. • It was found that the interface software (VXworks) had been programmed without a feature called ‘priority inheritance’. • JPL engineers uploaded a short C programme and Pathfinder did not experience anymore system resets.

  18. THANK YOU