Eindhoven University of Technology
MASTER
Evaluation of real-time operating systems, development methdologies and CASE-tools for PC based process-control
Lemmers, J.H.M.
Award date: 1996
Link to publication
Disclaimer This document contains a student thesis (bachelor's or master's), as authored by a student at Eindhoven University of Technology. Student theses are made available in the TU/e repository upon obtaining the required degree. The grade received is not published on the document as presented in the repository. The required complexity or quality of research of student theses may vary by program, and the required minimum study period may vary in duration.
General rights Copyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright owners and it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights.
• Users may download and print one copy of any publication from the public portal for the purpose of private study or research. • You may not further distribute the material or use it for any profit-making activity or commercial gain Eindhoven University of Technology Faculty of Electrical Engineering Section : Measurement and Control
Evaluation of real-time operating systems, development methodologies . and CASE-tools for PC based process-control by J.H.M Lemmers
M. Sc. Thesis Carried out trom September 1995 to August 1996 Commissioned by Prof. Dr. Ir. P.P.J. van den Bosch Under supervision ot Ir. C.A.M. v.d. Brekel and Ir. J.W.J.J. Beckers Date: August 15, 1996
The Department of Electrical Engineering of the Eindhoven University of Technology accepts no responsibility for the contents of M. Sc. Theses or reports on practical training periods. J.H.M. lemmers Summary
Summary
The key-word of this master thesis is time. The first part of the master thesis is an exploration of real-time operating systems and real-time software engineering. The second part covers the real-time behaviour of Windows NT 3.51 and the development of a measurement and control application.
A real-time system is a system which has to response predictabie and within time-constraints to extern events. An embedded system is a computer system, which is a part of a bigger system and plays a role essential to the functioning of this bigger system.
A real-time operating system is a operating system, designed to provide for the user-applica tions to meet their time-constrains. Real-time operating system are often very scaleable, opti mised on speed, predictabie.
This master thesis discusses the real-time operating systems QNX, VxWorks, VRTx and iRMX. A result of this survey is that the differences between the operating systems are more in the field of the development tools then in the field of architecture and performance.
Real-time software engineering introduces extra aspects, comparing to 'ordinary' software engineering. Additional aspects are time-constraints, complex behaviour, verification, vali dation and simulation. A closer look has been taken at structured development methodologies, functional oriented ( SAiSD by WardlMellor and SDl) or object oriented (Boaeh, OMT by Rumbaugh, CoadNourdon, Shlaer/Mellor).
It is almost impossible to exploit all the advantages of a structured methodology, if na CASE tooi is used. A CASE-tooi is a tooi to record, verify and validate produced system specifications and system architecture. Furthermore a CASE-tooi is able to support developers by generating documentation and generating automatically code. The master thesis discusses several CASE tools. These tools are common tools and tools specialised in real-time software development.
The last part of this master thesis discusses the determination of the real-time performance of Windows NT 3.51 in order to establish if Windows NT is suitable for measurement and control tasks. The response latency, the interrupt latency, the duration of the Interrupt Service Routine (ISR) and other relevant time periods are measured. In the ISR the control action takes place. The result of this measurement is that Windows NT is found suitable for measurement and control actions if the specifications measured are suitable for an algorithm developed.
The response Jatencies measured have a minimum value of 1O~s and a maximum value of 1 56~s • The variation in the response latency is the result of disk activities. So the maximum response latency can be decreased strongly by avoiding disk activities. With the specifications measured. a developer of a control algorithm is able to establish if Windows NT is capable of running this algorithm. The algorithm can be inserted in the Measurement and Control-appli cation (MeCon-application). This application is a framework for running and testing control algorithms on Windows NT.
1 99.99% of the values measured are within 56~s
Page i Table of contents J.H.M. lemmers
Table of contents
Summary 1 Table of contents 11 1. Introduction 1 2. DescriptIon of the master thesis 3 3. Introduction to real-time and embedded systems 5 3.1 Introduction 5 3.2 What is a real-time system 5 3.3 Software engineering 8 3.4 Development of real-time software 9 3.5 References , 10 4. A real-time operatlng system ..•••..•..••••...•.••••.•...••••.....•..•••....••••••....•...•••.••••.•.•..•...... ••• 11 4.1 Introduction 11 4.2 The real-time operating system 11 4.2.1 Differences between real-time and non-real-time operating systems 12 4.3 The kemel or the nucleus 13 4.3.1 Scheduling 15 4.3.2 Simultaneity 18 4.3.3 POSIX 19 4.4 Micro-kernels 20 4.5 Memory management. 20 4.6 Network facilities and distributed operating systems 21 4.7 Performance of a real-time operating system 23 4.8 References 24 5. Choosing a real-time operating system 25 5.1 Introduction 25 5.2 A customised reaI-time operating-system 25 5.3 A survey of real-time operating systems 26 5.3.1 QNX 26 5.3.2 VxWorks 28 5.3.3 VRTx 29 5.3.4 iRMX 30 5.3.5 Other real-time operating systems 30 5.4 Evaluation 31 5.5 References 32 6. Slructured development of real-time software 33 6.1 Introduction 33 6.2 Software development methods : 33 6.3 Software management 35 6.4 Software Iife-cycle '" 36 6.5 Functional versus object oriented methods 38 6.6 Real-time aspects of structured software-development.. 40 6.6.1 Handling events 40 6.6.2 Dynamic behaviour 41 6.7 Verification and validation 42 6.8 Survey of development methods 43 6.8.1 Structured Analysis and Structured Design (SA/5D) by Ward and Mellor 44 6.8.2 Specification and Description language (SOL) 47 6.8.3 Object Modeling Technique (OMT) by Rumbaugh and others 49 6.8.4 Object-Oriented Design (000) by Booch 51 6.8.5 Object oriented AnalysislDesign (OOA/D) by ShlaerlMellor 53 page ii J.H.M. Lemmers Table of contents
6.8.6 Real-time Object Oriented Method (ROOM) 55 6.8.7 Object Oriented Analyse/Design (OOA/OOD) by Coad and Yourdon 57 6.8.8 Other methods 58 6.9 Evaluation 59 6.1 0 References ~ 60 7. A survey of CASE·tools..•••.•••••••••••.••, 63 7.1 Introduction 63 7.2 A CASE-tooi 63 7.3 Code-generatian 64 7.4 The selection of a CASE-tool. 65 7.5 Su rvey of case-toaIs 66 7.5.1 ObjectGEODE and LOV OMT by Verilog 67 7.5.2 ObjecTime by ObjecTirne lirn 68 7.5.3 SDT by Telelogic 68 7.5.4 ObjectTeam by Cadre Technologies Inc 69 7.6 Evaluation 70 7.7 References 71 8. The suitablllty of Windows NT for measurement and control purposes 73 8.1 Introduction 73 8.2 Purpose of the measurernent. 73 8.3 The measurement methods 75 8.4 The test setup 79 8.5 The measurement expectation 80 8.6 The measurement results 81 8.7 Specifications 84 8.8 Control algorithms and computational delay 85 8.9 Evaluation 87 8.10 References 87 9. Development of the measurement and control applIcation (MeCon) 89 9.1 Introduction 89 9.2 Analysis of the MeCon application 89 9.3 Design of the MeCon application 91 9.4 Implementation 93 9.5 Inserting an algorithm 94 9.6 Conclusion 94 9.7 References 94 10. Evaluatlon and recommendations 95
Appendix A Summary real-time operating systems specifications 97 Appendix B Comparison of object-oriented methods 100 Appendix C Comparison of functional·oriented methods 101 Appendix 0 Summary CASE-tools specifications 102 Appendix E Windows NT 107 Appendix F Microsoft Foundation Class (MFC) 116 Appendix G Device Drivers tor Windows NT 117 Appendix H Measurements data 121 Appendix I List of used terms 130
pageiii Table of contents J.H.M. Lemmers
page iv J.H.M. Lemmers Introduction Chapter 1
1. Introduction
Time is a very important aspect of technical applications. For example a system has to re sponse within a certain time period or a digital controller has to retrieve samples and has to send outputs within time-constrains, to guarantee that the controller works correctly. A system, which has to respond within established time-constraints, is called a real-time system. Chapter 3 contains a discussion about real-time and embedded systems.
These timing demands have influence on technical computer systems. The design of hardware and software must be prepared, resulting in special reaI-time operating systems and software development methodologies for real-time applications. Real-time operating systems are discussed in chapter 4 and chapter 5 and real-time software engineering is discussed in chapter 6 to chapter 7.
Also the measurement and control group needs real-time systems, to execute contraI opera tions. These operations can be executed by PC-equipment running Windows 3.1, but these systems have a low capacity and a bad real-time behaviour. An altemative is an expensive DPC-system.
However, the measurement and control group prefers the use ot cheap PC-equipment with good real-time behaviour. These systems must be equipped with a real-time operating system or another operating system with good real-time specifications. Such a candidate is Windows NT, an operating system for the future. Chapter 8 and chapter 9 discuss the use of Windows NT for measurement and control purposes.
I want to finish this introduction by thanking the measurement and contral group for the opportunity to do this very interesting and educational master thesis. Furthermore I want to thank Prot. Dr. Ir. P.P.J. van den Bosch, Ir. CAM. van den Brekel and Ir. J.W.J.J. Beckers and the other members ot the measurement and contral graup tor their time, their support and their suggestions during the eleven months I spent to this master thesis. Furthermore I want to thank P.E. Kamphuis tor developing the DSP-application to measure the response latency and Ir. L.J.M. Cluitmans of the medical technology graup tor making available Microsoft's Software Development Kit (SDK).
page 1 Chapter 1 Introductlon J.H.M. Lemmers
page 2 J.H.M. Lemmers DescriptIon of the master thesis Chapter 2
2. Description of the master thesis
The theme of this master thesis is real-time applications on a Personal Computer (pC). The purpose is to get experience and insight in running real-time applications on a PC. This master thesis is divided in two parts.
The first part of the master thesis is an evaluation of operating systems, structured development methodologies and CASE-tools, which make a personal computer suitable for running real-time application"s. The purpose of the survey is to orientate and to examine the possibilities.
The advantages and disadvantages and the specific area of application of a selection of operating systems is mentioned. The development methodologies are evaluated upon level of quality and the suitability for real-time applications. Development methodologies are strongly related to CASE-tools. The evaluation of CASE-tools is pointed to the suitability for real-time applications. the support of methodologies. the quality of the automatic code generation and level of appl iance in combination with real-time operating systems.
The second part of the master thesis is an examination of the real-time performance and the real-time qualities of Windows NT. Further is examined if Windows NT is a suitable operating system for measurement'and control work. The environment created can be used by fellow workers at the measurement and control group for development and running of real-time software.
page 3 Ch~pter 3 Introduction to reaI-time and embedded systems J.H.M. Lemmers
page 4 J.H.M. Lemmers Introduction to real-time and embedded systems Chapter 3
3. Introduction to real-time and embedded systems
3.1 Introduction
In this chapter the terms real-time systems, embedded systems and software engineering are introduced. This chapter outlines a global image of the area, this master thesis applies to and provides an overall picture for the reader, when reading the following chapters.
3.2 What is a reaI-time system
A computer system is a machine, which can be used in different kind of applications. 1I can be used as an information manager or as a controller of a technical system. Examples of the last mentioned situation are flight control systems in aeroplanes and computer systems controlling industrial plants.
In these cases the computer is interfacing an external process, resulting in the fact that the computer system has to react to asynchronous events. It is a reactive system. The accuracy of the system depends not only on the logical result of a computation, but also on the time at which the results are produced and the predictability of such time. In such a case, where a computer system has to perform within time-limits, you are dealing with a real-time system (see figure 3-1).
Real-time systems have the following characteristics: • the system interacls directly with its environment • the system plays a role essential to the continuous functioning of the environment • correct and continuous service is of critical importanee • the behaviour is complex • much interfacing with hardware of the process and other computer systems • simultaneous processing of input and output • mostly fast responses are required • real-time computer systems are tuned on worst-case behaviour and situations. • the behaviour and the performance of a real-time system must be predictabie to guarantee that a specific requirement will be fulfilled.
Real-time systems mostly have to deal with asynchronous events, which means the arrival of events is (almost) not predictabie. An event is something that happens at a point in time and is instantaneous (takes zero time) and atomie (happens completely or not al all) (source [ 3-2 J).
On basis of time-constraints real-time systems can be divided in hard or soft real-time. Hard reaI-time conventionally means that the important tasks have deadlines that always must be met, otherwise the system has failed. For example, it is disastrous for passengers of a car if an airbag contro\ system responds to late to an accident. Also a soft real-time system requires the ability to meet deadlines, however failure to do so does not mean the system failed. For example in some cases a sensor sample can be missed, because the missed sample can be interpolated.
Page 5 Chapter3 Introductlon to real-tlme and embedded systems J.H.M. Lemmers
Slower 15
100ms ::;~~~~Af~~L~:\ ';:.:',,", ~l<' ~>;~.~ ·Me~i.~I.t;;,,~; . J~(acess, d~.Q!lÓ§.iU!l!l .-:------1 'control lab automallon 10ms . systeins Robot 'and controllers 1ms Industrial Response Telemetry Automation . controland Time seismIe analysls 100us Proeess sImulation and network contral 10us . F1ight Simulatiori 1us Faster 100n5 Application "gure 3·1 Response-time requirements for real-time applications (source [ 3-4 ])
An embedded system is a computer system, which is a part of a bigger system. It is not directly visible nor accessible and mostly real-time. An embedded computer system interacts directly with its environment and plays a role essential to the continuous functioning of the environment (see figure 3-2). Embedded system usually have got the following characteristics: • the system is specially designed and equipped for the task it wiJl execute • the system will only executed the task it's designed for • mostly high performance is requested • applications are put on ROM or are loaded using a network • special functional stripped and tuned hardware and software • embedded systems can be produced in large numbers (consumer products) or can be unique ( industrial products). • Iimited human interfacing, so that special development equipment is needed ( for example host-target platforms) Examples of embedded systems are computer systems built in copy-machines, laser-printers and coffee-machines.
Environment
Embedded computer Outputs system
flgure 3·2 Embedded systems
page 6 J.H.M. lemmers Introduction to reaI-time and embedded systems Chapter 3
Real time and embedded applications usually exist in a hierarchy consisting of three levels: control, supervisory and management (see figure 3-3). Control, the lowest level of the hierarchy is typically reactive, smalI, standalone and generally oblivious to other systems. The second level is usually a supervisory control and computing system with loosely defined real-time operations, Iike production scheduling and control and process optimisation. At the highest level, the management level, computing is non-real-time. These systems generally handle business operations, such as manutacturing-resource planning and order procesing.
, Controllevel Control level hard-real-time computers hard-real-time computers
figure 3-3 Control hierarchy
Page 7 Chapter3 Introductlon to real-time and embedded systems J.H.M. Lemmers
3.3 Software engineering
Since the invention of the computer, the size and complexity of software has been growing. The traditional method of implementing functions in software has led to a situation where the size and complexity of software has become unmanageable. Software projects started to run behind schedule, exceed their estimated costs and did not fully meet customer requirements. More overhead, communication and co-ordination problems appeared, when the amount of people working at one project increased.
Software~developers needed techniques and tools to compensate the human limitations in managing software complexity. Proper and efficient use of such methods and tools is the discipline commonly known as software engineering.
The software engineer has to build modifiable, efficient, reliable and understandable software. Unfortunately software developers often meet inconsistent and obscure requirements, strong time constraints, hardware obstacles and integration problems.
The most important goal of software engineering is to increase the quality of the product and to let the product meet the specified requirements, before the agreed point of time. System quality is the systems ability to satisfy the needs and expectations of the users and the owners, Le. the system environment. Consequently, this first issue in quality contral is to understand the needs and expectations of the environment. This environment consists of users, owners and other systems.
The essence of quality control is therefore to ensure that each communication link and transformation step works as intended. There are two aspects to this: • The overall process The organisation of the development process into major steps where specific documents are produced and certain quality assessment procedures performed (ISO 9000 ). • The technical contents The information contents of the various documents produced, e.g. requirements specifications, systems specifications and test plans.
The various descriptions are produced by activities that are ideally performed in a chronological ordered sequence, for example the waterfall model (see paragraph 6.2.1). Closely related to the design strategyis the design methodology. A design methodologyprescribes a set of descriptions and associated methods to achieve the right quality, short lead times and low cost. Clear and precise descriptions, symbolic representations of the subject matter, are essential for all our understanding, analysis and communication. In chapter 6 methodologies are further worked out.
Ouring the design process several documents are produced. Documents are the logical carriers of descriptions. Examples of documents are functional and non-functional requirements, quality plan, project plan, test plan, user's manual, test documents, operators manual and the functional and implementation design.
page 8 J.H.M. Lemmers Introduction to real·time and embedded systems Chapter3
3.4 Development of real-time software
There are many big differences between real-time software development and normal software development. Particular characteristics of real-time software development are: • time constraints • the environment mostly possess complex dynamic behaviour • much more hardware interfacing • difficulties to test and debug an applïcation.
The software development techniques must provide facilities to record the time constraints and the complex dynamic behaviour. However, recording only the time constraints is not enough. At the end of the development process, and preferabie in an early stages, a check must take place if the time constraints are met.
Extensive simulation of the developed software system during all the software development stages gives large advantages, because in early stages it is possible to determine if the time constraints are met with the chosen configuration and the chosen software architecture. In the early stages it is much easier and cheaper to adjust the specifications, the hardware configuration or the software architecture. Besides simulation can be much cheaper and easier than testing the software on the real hardware, because the hardware can be very expensive and rare. And it can be very hard or not possible to create particular states or situations ( for example a failure state in a nuclear plant). The last advantage I want to mention is the possibility to evaluate the software although the hardware is not available vet.
The last aspect of real-time software engineering is testing and debugging of the developed code. The only way to be sure the system will provide the right quality is to test the real-time behaviour at real speed. The developer has to check several processes and variables simultaneous. Further it is hard to test all possible situations, which can occur during the working phase of the system. And if during testing.all time constraints are met, there is no guarantee that all time constraints in all possible situations will be met.
The conclusion is that development of real-time software requires special tools and techniques. This master thesis discusses these tools and techniques.
Page 9 Chapter 3 Introductlon to reaI-time and embedded systems J.H.M. Lemmers
3.5 References
Books: [3-1] Rolv Braek and Oystein Haugen Engineering Real Time Systems ; An object-oriented methodology using SOL Prentice Hallinternalional Ltd., 1993, ISBN 0-13-034448-6 [3-2] Shem -Tov Levi and Ashok K. Agrawala Real-time system design McGraw-HiII inc, 1990, ISBN 0-07-037491-0
Articles: [ 3-3 ] E. Oouglas Jensen Oistributed real-time operating systems Or.Oobb's Journal. February 1995, page 32-38 [ 3-4] B. Furht and W.A. Halang A survey of real-time computing systems International journalof mine- and microcomputers, Vol. 16, No. 3, 1994, page 141-155 [ 3-5] Fabio Panzieri and Renzo Oavoli Real Time Systems: A TutoriaJ Performance evaluation on computer and communication systems ; joint tutorial papers performance '93 and sigmetrics '93. 1993
page 10 J.H.M. Lemmers A real-tlme operatlng system Chapter4
4. A real-time operating system
4.1 Introduction
The aim of this chapter is to explain and discuss technical terms mentioned when you get in touch with operating systems. This chapter focuses on real-time operating systems.
4.2 The real-time operating system
Every computer system needs a operating system, to execute co-ordinating and administrating work for the users of the computer system. The operating system is the layer between the users-applications and the computer-hardware and it provides facilities for the users to share efficientlyand reliably the computer hardware, by managing the resources.
The operating system is divided in the next subsystems: • the nucleus or kemel The nucleus is the heart of the operating system. It manages the processes, supports the input/output activities and supports the file system. • the memory manager the memory manager applies for the processes access to the memory. • the shetl the shell provides the interfacing between the users and the system. • the network manager the network manager provides access to connected networks.
Computers can be used in a wide area of application. Every application has its own demand to the operating system. So there are a lot of different operating systems, all specialised in their application-domain. One of such domain is the real-time applications-domain.
Real-time operating systems are designed to provide for the user-applications to meet their time-constraints. It has to respond predictablyand regularlyas weil as within certain time constraints to extemal events. The major characteristics of real-time operating systems are: • The used scheduling policies are based on highest priority first and remains control of a recourse until it has completed or until it does not need this resource any more • The used scheduling policies and the other operations are highly preemptive. Examples of such operations are interrupt service routines, critical areas. • The functionality offered by the real-time operating systems is highly adjustable.
Page 11 Chapter 4 A real-time operatlng system J.H.M. Lemmers
4.2.1 Differences between real-time and non-real-time operating systems
There are many differences between a real-time operatlng system and a general operating system. Therefore it is difficult to change a general operating system into a real-time operating system. The differences are: • bad scheduling policies for process scheduling and internal queues • the timer facilities of a general operating system are to coarse • memory management contains no method for locking pages into (virtual) memory • inter-process communication facilities do not support fast and predictabie communication • intolerab\e overhead • excessive latency in responding to interrupts • non-preemptability of the kemel and kemel functions • it is rlot possible to adjust the provided functionaJity of a non-real-time operating systems, what can be very desirabie for embedded system developers • the operating system is optimised for average case and not for worst case behaviour • poor predictability.
In general software systems, the main goal of a general operating systems is efficient use of available resources during average behaviour. In contrast to real-time systems, where the main goal is to satisfy to timing-constraints, during worst case behaviour. This results in high capacity-demands comparing to general computer systems.
Also non-real-time operating systems are usefuJ for running real-time software. However developers have to watch for pittalls. A non-real-time operating system is not equipped and not tuned for worst-case behaviour, so unpredictable and unexpected incidents can occur. Reasons for this behaviour can be for example wrong scheduling policies, priority inversion and disk access for virtual memory management. Problems increase when more then one rea/-time task is operating.
But non-real-time systems can be suitable, dependent of the required performance and functionality. An example of non-real-time systems use for real-time applications is a soft real time operator/management application, used for supervisor and management systems (see figure 3-3). Furthermore non-real-time systems can be interesting if developers are already familiar with an operating system and the cost of software and hardware are much lower compared to real-time operating systems' and hardware.
In this master thesis attention is paid to only one non-rea\-time operating system, Windows NT. Windows NT has high potential power, especially for supervisor and management applications. Appendix E includes a description of Windows NT.
page 12 J.H.M. Lemmers A reaI-time operatlng system Chapter4
4.3 The kemel or the nucleus
All of the operations involving processes are controlled by a part of the operating system, the nucleus. This part is also referred to as the core or the kemel. It is the most intensively used code of the operating system. The nucleus is a shell around the hardware. It provides an environment for processes torun independent and simultaneous and enables tasks to share resources (see figure 4-1). The nucleus is involved in : • process and thread administration • dispatching and scheduling • interrupt processing • hardware interfacing • inter-process communication and process synchroniSition.
Awake ...... Asleep
figure 4-1 The nucleus layer figure 4-2 Process state transitions
In literature there are many definition of a process. In general a process or a task is defined as a stream of instructions, an independent piece of program in execution. Every process has a private address-space. The nucleus manages a complete administration of all processes. A process can be in one of the next states (figure 4-2): • running-state A process, occupying a processor, is in running-state. This applies only for one process for every processor at the time. • 'ready to run'-state The other processes, which are ready to run at a processor but not scheduled to one, are in 'ready to run'-state • blocked-state Processes, which can not proceed, are in blocked-state. The blocking can for example be caused by not-accessible resources or critica' areas or because the process is waiting for events or data. Each process maintains a private address-space to ensure that it will not interfere with other processes.
Inside a process can exist blocks of instructions exist, which are independent of each other. These blocks are suitable tor parallel execution. This can be achieved by using threads. A thread is a lightweight process and enables a process to use multithread execution in a more efficient way. Threads are using the address-space of the owning process.
Page 13 Chapter4 A reaI-time operating system J.H.M. Lemmers
Processes need resources to execute.. A resource can be a hardware device (e.g. a tape drive) or a piece of information (e.g., a locked record in a data base). Resources have all kinds of characteristics: In short, a resource is anything that can only be used by a single process at any instant of time (source [ 4-5 ]). • an exclusive or a shareable resource Exclusive resources can not be shared by one user at a time, Iike a processor or a printer. Shareable resources can be used by many users, Iike memory or a disk. • a preemptable or a non-preemptable resource A preemptable resource can be taken back from a source by the operating system. A non-preemptable resourcecan only be given back to the operating system by a resource-user. • a reusable or consumable resource A reusable resource can be used more then once, Iike memory or the printer. A consumable resourcecan only be used ones, Iike processor-time or paper. • a physical or a logical resource Physical resources have a direct connection to hardware, Iike a printer. Logical resources exist because the existence of a signalor they have arelation to the contents of a memory bloek, for example a message, a time signalor the contents of an input file. The eharacteristics of a resource are dynamic and sometimes adjustable.
page 14 J.H.M. Lemmers A real-time operating system Chapter4
4.3.1 Scheduling
The number of processes, claiming a particular resource-type, almost always exceeds the number of resources available. The nucleus has to provide a mechanism that enables processes to share resources. The operating system has to determine when resources should be assigned to a process. This is called scheduling. The scheduling algorithms used have to contribute to the main goal of a real-time operating system, the processes have to satisfy to timing constraints and have to be completed within an acceptable time span.
As mentioned earlier, a resource can be preemptive or non-preemptive. The control over non preemptive resources can only be returned to the operating system by the resource-user. The advantages of such technique are: • increased 1/0 processing performance • simple construction • less overhead • maximum efficiency.
Process A Blocked High priority [:::=J Ready to run Process B Running Low priority E:=J CD® ~ 1 process A has started and tums into 'ready to run'-state, process B keeps running 2 process B can not go on and is blocked, process A starts running 3 process A can not go on and is blocked, process B starts running 4 process B can not go on and is blocked, process A starts running 5 process A has finished, process B starts running figure 4-3 Example of non-preemptive scheduling
The advantage of preemptive scheduling is reducing response times, a very important aspect in real-time computing. 50 preemptivity is a very important aspect of a real-time operating system and is applicable to processor- and resource-scheduling and operating system functions.
__ Blocked
o Ready to run Process B (01 14 k Low priority LO-..L-__--L..~_"'__----L -"-----' I<,/1 Running CD ® ® 8) 1 process A has started, process B tums into 'ready to run'-state 2 process Acannot go on and is blocked, process B resumes running 3 process A awakes and starts running, process B is blocked 4 process A has finished, process B starts running figure 4-4 Example of preemptive scheduling
Scheduling algorithms are statie or dynamic. Statie algorithms are easy to implement and have less overhead. Dynamic algorithms have more overhead, but the overhead is hopefully justified by the increased responsiveness of the system. An adaptive mechanism responds to the changing behaviour of the system it controls. Adaptive mechanisms generally require more overhead than non-adaptive ones, but the resulting sensitivity to changes in the system makes the system more responsive and helps justify the increased overhead.
Page 15 \ l
Chapter4 A reaI-time operating system J.H.M. Lemmers
Scheduling algorithms have a great impact on the behaviour of the computer system. Especially the processor-scheduling policy. There are several approaches: • First In, First Out (FIFa) scheduling Perhaps the simpJest scheduling is First-In-First-Out seheduling. FIFO is non preemptive. and not suitable for real-time systems. However FIFO is often used embedded within other scheduling policies. • Round robin scheduling In round robin scheduling, processes are dispatched FIFO but are given a limited amount of epu time, called a time-slice or a quantum. • Statie table driven approaches This approach is applicable to tasks, which are periodie or have been transformed into periodic tasks. A table is constructed that identifies the start and completion times of each task and tasks are dispatched according to this tabie. This approach is very inflexible in spite of the possibility to create different tabJes for situations with different kind of characteristics. • Priority driven preemptive approaches This is the most well-known approach. It contains statie or dynamic priority assignment to a process related to the timing constraints. The task with the highest priority is executed first. The priority assignment depends upon the used a1gorithm: 1. The designer assigns the highest priorities to the most important tasks. This approach is most common used. This scheduling policy is often extended with round robin scheduling for processes with equal priority. 2. the Rate-Monotonie (RM) algorithm : higher priorities are assigned to tasks with shorter execution periods. This algorithm causes increasing average response time. 3. the Earliest-Deadline-First (EDF) algorithm : a closer a task's deadline, the higher its priority. 4. the least-Iaxity (LLF) algorithm : the laxity is defined by the amount of time one can wait and still meet its deadline. The smaller the proeess-Iaxity, the higher its priority. For tasks, with an equal priority level, an alternative scheduling policy must be used, for example FIFQ or Round Robin. • Dynamic planning-based approaches After a task arrives, but before its execution begins, an attempt is made to create a schedule that contains the previously guaranteed tasks as weil as the new arrival. • Dynamic best eftort approaches In these approaches the system tries to do its best to meet deadlines, but, in contrast to the dynamic planning-based approaches, na guarantees are provided whether a timing constraint will be met. As you can imagine the dynamic approaches have large overhead, but offer better service and chances the timing constraints will be met.
page 16 J.H.M. Lemmers A reaI-time operating system Chapter4
One of the concems of real-time computing is priority-inversion. The nucleus is dealing with priority-inversion if an important high-priority process is prevented from execution by a lower priority process for an indefinite period of time. This delay is caused by lower-priority processes, holding a resource or processing a critical area. Priority-inversion can be prevented or decreased by : • smal! critical sections • interru-pt service routines should be as short as possible • preemptive resources • preemptive operating system-functions • the scheduler can increase now and then the priority of a low-priority process. 11 this process has claimed a critical area or a resource, needed by a high priority process, this resource or critical area will come available.
Process A High priority
< 1 A is blocked, B is running 1 Benters the critical area 2 A starts running, B is blocked e 3 A wants to enter the critical area occupied by Band is blocked, B starts running 4 B leaves the critical area and is blocked, A starts running 5 A leaves critical area 6 A has finished, B starts running figure 4-5 Example priority-inversion
Page 17 Chapter4 A reaI-time operating system J.H.M. Lemmers
4.3.2 Simultaneity
Processes in a real-time system are strongly related to each ather. They exchange and share data and resources, they communicate and steer each others progress to synchronise. The operating system offers special facilities to support inter-process communication.
When a process is accessing shared modifiable data, the process is said to be in a critical section (see figure 4-6). To prove for such areas correct processing, it is essential that only one process at any time is inside a critical area.
A protecting mechanism of critical areas has to satisfy to the following conditions: • it must be general and for non-planned situations • usabIe for an unlimited amourit of users • deadlock and individual starvation must be prevented critical • efficient, so no busy waiting section • time-invariant.
Such a synchronisation facility is a semaphore. A semaphore is build up out of a protected variabie (S), a counter or a binary value, and a P-operation and a V-operation to access the data-structure. The P-operations operates as follows: if 8>0 1 then 5:=8-1 else (Wait on 8 ) The process passes the P-operation immediate if the S-value is. ... bigger then 0 or it waits until it is released by another process. A flgure 4-6 Crltlcal sectIon process is released or the S-value is increased by the V-operation, which operates as fdlow : if ( one or more processes are waiting on S) then ( let one of these processes proceed ) else 5 := 8 + 1
There are several semaphore variants. For examplethe general or binary semaphore, the conditional semaphore and the (non)-time-restricted semaphore. The semaphore can be used for screening critical areas and for synchronisation.
Another synchronisation facility is a mailbox, a message queue that may be used by multiple senders and receivers. Senders can fill the mailbox unrestricted with data-structures and receivers can retrieve the data-structures. If the mailbox-queue is empty, the receiver can stay asleep until a message is posted.
A pipe is introduced by UNIX and is essentially a mailbox which allows a specified number of characters to be removed at once.
If a process wants to claim a resource or a critical area, which is already claimed,or if no data is available, the process is not able to continue. The kemel will put such a process in blocked state. A process is never allowed to use busy waiting (keep polling if data, a resource or critical area is available). Busy waiting is fatal tor performance and results sometimes in incorrect system behaviour.
page 18 J.H.M. Lemmers A real-time operating system Chapter 4
4.3.3 POSIX
POSIX (Portable Operating System Interface) is initially launched in 1984 as an eftort to standardise the UNIX operating system. POSIX later became the basis of the IEEE 1003.1 standard (source [4-7 D. POSIX is both a standards-making body operating within the IEEE and the name given to the family of standards created by this group. The POSIX standards include the 1003.1 (system API). 1003.2 (shell and utilities). and 1003.4 (real-time extensions) standards.
The IEEE 1003.1 forms the central core of POSIX on which the rest of POSIX is attached. It provides the essentials of a stripped-down UNIX system and it includes: • process primitives • signals • basic file access and file system namespace • terminal interface • backup format • user administration and basic security facilities • simple interprocess communication • localisation function for internationalisation The 1003.4, the real-time extension to POSIX. was formally approved in September 1993.
The advantages of a standards making body like POSIX are: • increase the level of applications portability among heterogeneous computing systems • allow portability and interoperability of software tools • make purchasing UNIX-based software easier.
Page 19 Chapter 4 A reaI-time operating system J.H.M. Lemmers
4.4 Micro-kernels
Micro-kemels are small fast kemels and are usually highly specialised to an application. To achieve speed and predictability, the kemels are stripped down and optimised versions of time sharing operating systems or reaI-time operating systems To reduce the run-time overhead, incurred by the kemel, and to make the system fast, the kemel: • has a fast context switch • has a small size and thus minimal functionality • responds quickly to external interrupts • minimises intervals during which interrupts are disabled • provides fixed or variabie sized partitions for memory management as weil as the abiJity to lock code and data in memory • provides special sequential files that can accumulate data at a fast rate.
Micro-kemels can be bought outdoors or be home-made. There are commercial versions available as freeware or at a low price. Writing a kemel indoors is not a very sensible decision, because of the time needed to develop a kemel, while kemels are available for a low price. Furthermore a vendor offers not only an extensive tested kemel, but also support, documen· tation and tools. Micro-kemels are available from small kemels for free to highly professional and weil equipped kemels.
4.5 Memory management
On top of the nucleus-Iayer there is the memory-management-Iayer. The memory-manager is responsible for access to the fast intemal memory, also called real, main or primary memory.
There are several addressing methods available, each having several advantages and disadvantages for real-time computing: • linear memory model The Jinear memory model maps all memory areas into a single address space. This model needs a Iinking loader, placing programsinto the memory. Further memory-access protection is not possible. An advantage is that no address translation mechanism is needed. • fixed size or variabie memory partions, using segments or pages Using memory blocks, the operating system is abIe to put programs and data flexible in the physical memory. Further it is possible to provide memory-access protection. However there must be address translation mechanisms facilities and mechanisms to check partition boundaries. • virtual memory The memory-manager is able to provide more memory to processes, then physical is present in the computer. This technique is called virtual memory. Blocks of virtual memory, which cannot be placed in the intemal memory are temporally stored on the hard disk. The exchange of memory-pages between real-memory and hard disk is a time consuming operation. So in real-time operating systems using virtual memory, it must be possible to loek memory-pages, so all facilities needed by processes with time-constraints stay direct available in the intemal memory. Further the exchange of memory between the physical memory and the disk-memory must have no effect on the real-time performance.
The operating system can provide memory protection, to determine if an accessed address location is not used, if the process has no access-rights to the location or the wrong operation is applied on the memory location. Memory protection contributes strongly to the software-quality and stability, but introduces extra load for the processor and the operating system.
page 20 J.H.M. Lemmers A real-tlme operatlng system Chapter4
4.6· Network facilities and distributed operating systems
Local area networks and fast wide area networks provide an opportunity to connect computers. The major reasons for using a network are: • a need for sharing resources and information • increasing computer performance within the bounds of the processor capacity, by dividing the functionality among specialised computers.
Network operating systems are a collection of operating systems of computers connected to a network incorporating modules to provide access to remote resources (seefigure 4-7). The network operating system links and coordinates remote actions and communication between local operating systems. The network operating system layer provides the following services: • accepting requests for performing remote operations • determining the location of necessary resources • defining ways of initiation of these operating and retuming services. A disadvantage is a user needs to know the location .of a requested resource.
A distributed operating system is one that looks to its user Iike an ordinary centralised operating system, but runs on multiple independent central processing units (seefigure 4-8). The use of multiple processors should be invisible to the user or the user views the system as a virtual uniprocessor, not as a collection of distinct machines connected by a communication subsystem Characteristics of a distributed operating system are: • each computer runs agiobal, system-wide operating system • the operating system dynamically allocate processes to CPUs • if an user want to access a resources, he don't need to know the resource's location • the operating system manages the placement of files.
A network operating system has the following set of characteristics that distinguishes it from a distributed operating system: • Each computer has its private operating system, instead of running part of agiobal, system wide operating system. • Each user normally works on his own computer or on a designated computer. Using a different computer requires some kind of 'remote login', instead of having the operating system dynamïcally allocate processes to CPUs. • Users are usually aware of where each of their files is stored and must move files between computers with explicit 'file transfer' commands, instead of having file placement managed by the operating system.
user user user processes processes processes local local operating system operating system network network distributed operating system operating system operating system communication communication module module t ! t
flgure 4-7 Structure of a network operating figure 4-8 Structure of a distributed system operating system
Page 21 Chapter4 A reaI-time operating system J.H.M. Lemmers
A good interprocess communication facility is important because of the need to provide access to resources distributed over a local area network ( in same cases over local and wide area networks) in a uniform manner independent of language, network location, or in some cases, host operating systems. To achieve this goal, the interprocess communication facility must provide policies and mechanisms to effect local and remote communication between consenting process, and between processes and resources.
Different sets of primitives can be used in remote interprocess communication. However, the most common are based on: • message passing Message passing has the lowest level of abstraction. The encoding en the decoding of the messages must be implemented by the developer. • Remote Procedure Call (RPC) The very general term remote procedure call means a type-checked mechanism that permits a language-Ievel caU on one computer to be automatically tumed into a corresponding language-Ievel caU on another computer.
page 22 J.H.M. Lemmers A real-time operating system Chapter4
4.7 Performance of a reaI-time operating system
Real-time systems have to response to events within predictabie time-constraints. But first the definition of the time-constraints has to be established: • The input response time or input latency the time between the time sensors detect some change in the environment and actuators complete their response (see figure 4-9). • The interrupt latency the time between the interrupt arrives at the processor and the start of the interrupt service routine (see figure 4-10). • The process rescheduling time after a interrupt the time the operating system needs to reschedule, to start a new process • the interrupt termination time • the context switch.
The absolute values of the performance are important, but also the variation in these values.
Interrupt Interrupt handIer Interrupt handIer Interrupted process continues occurs runs finishes or driver process starts ! ! ! ! tr I litt interrupt interrupt latency termination interrupt time service routine figure 4-9 Definition input response time
interrupt occurs t I
Tlatency 11 Tdispatch I interrupt latency interrupt dispatch time
Tdisable interrupt disable time
Interrupt latency figure 4·10 Definition interrupt latency
Page 23 Chapter4 A real-tlme operating system J.H.M. Lemmers
4.8 References
Books and lecture notes: [ 4-1] H.M. Deitel Operating Systems, second edition Addison-Wesley Publishing Company, 1990, ISBN 0-201-50939-3 [ 4-2] Ir. A.G.M Geurts Besturingsprogrammatuur voor digitale systemen 1 TUE, Colledictaat nummer 5735, Oktober 1994 [ 4-3] A. Goscinski Distributed operating systems ; The logical design Addison-Wesley Publishing company, 1991, ISBN 0 201 417049 [ 4-4] Andrew S.Tanenbaum Computer Netwerken Prentice Hall, 1988, ISBN 90-6233-497-0 [4-5] Andrew S.Tanenbaum Modem Operating Systems Prentice Hall, 1992, ISBN 0-13-595752-4
Articles: [ 4-6 ] Alberto Daniel Ferrari Real-time scheduling algorithms Dr.Dobb's Journal, December 1994, page 60 [ 4-7 ] Moses Joseph Is POSIX appropriate for embedded systems? Embedded Systems Programming, July 1995, page 90 [ 4-8] M. Maechtel and H. Rzehak On realtime operating systems : How to compare performance IFAC Real Time programming, 1994, pagina 139 [ 4-9] Krithi Ramamritham and A. Stankovic Scheduling algorithms and operating systems support for real-time systems Proceedings of the IEEE, vol. 82, no. 1, January 1994, page 55. [ 4-10] Krzysztof M. Sacha Measuring the real-time operating system performance Proc. 7'h Euromicro workshop on real-time systems, 1995, page 34 [ 4-11 ] Bernard Thome, Brigitte Glas and Robert Nahm Validation of real-time systems ; from "soft" to "hard" Proceedings 1994 tutorial and workshop on systems engineering of computer based systems, page 152
page 24 J.H.M. Lemmers Choosing a reaI-time operating system Chapter 5
5. Choosing a real-time operating system
5.1 Jntroduction
In this chapter a check-list is introduced, which is used to evaluate a number of real-time operating systems. If you are looking for a suitable operating system, you can use this check list for establishing your demands on functionality and performance. This chapter also contains a survey of real-time operating systems.
5.2 A customised reaJ-time operating-system
The operating systems are evaluated on the following points: A. general operating systems demands 1. how many task the nucleus is able to handle 2. the possibility to use threads 3. what process synchronisation-mechanism is supported 4. what kind of human interfacing is supported 5. what kind of graphical facilities are supported 6. what kind of processors are supported 7. what network facilities are supported and is a real-time network supported 8. are single or multi-processors supported 9. is it a distributed operating system 10.is it an object oriented operating system 11.how does the operating system react to crashes of running applications 12.the level of stability of the operating system 13.facilities for protection of memory-blocks and operating system data-areas 14.hardware-requirements, Iike minimum memory B. special real-time demands 1. is hard- or soft-real-time supported 2. the size of the kemel 3. is asynchronous 1/0 supported 4. is the operating system able to run from ROM 5. are operating systems-functions preemptive or non-preemptive 6. are mechanisms supported to stop or decrease priority-inversion C. performance-demands 1. predictability and determination of performance 2. overhead 3. response-performance D. development 1. available compilers, program-Ianguages and development tools 2. available CASE-tools, generating code specific to the operating system 3. the expected growth potentialof a tooI E.support 1. is it possible to run DOS or Windows programs 2. is it possible to read DOS-floppy-disks F. various 1. cost 2. popularity and acceptation in industrial and academie areas 3. continuity of service 4. references
Page 25 Chapter4 A real-time operatlng system J.H.M. Lemmers
5.3 A survey of real-time operating systems
The next paragraphs contain a survey of real-time operating systems. In appendix A a summary of the following data is placed, including references on suppliers.
The selected real-time operating systems are specially designed for real-time operating purposes. They are weil documented and supported, already have a large market share and they have shown their quality in practice. The selection is a\50 based on the criteria if the operating systems are mentioned in literature surveys and in newsgroups on the Internet.
5.3.1 QNX
QNX is one of the leading operating systems for pes, providing POSIX- and UNIX-compatible services. ONX is real-time, preemptive, prioritised, multitasking and multi-user. QNX is scaleable to the hardware on which it will run, accommodating everything from high-end servers and deve/opment systems, to compact, ROM based embedded systems.
The ONX operating system consists of a 10K micro-kemel and a team of modules. ONX uses multiple modules and messages passing for the 'base' operating system, which replaces a large kemel used at other operating systems. These modules are threaded like a user process, so only those system processes that are required are running. Examples of sueh modules are: • the process manager (Proc), the only mandatory, resource manager, providing services such as process creation, process accounting and memory management • the filesystem manager (Fsys) providing the filesystem • the device manager (Dev) providing device contra!.
Network mana er
Interrupts figure 5-1 The QNX micro-kemel
The QN~ kemel implements four services: inter-process communication, low-Ievel network communication, process scheduling and interrupt dispatching. The kemel provides fully preemptive, prioritised context switching, with round-robin, FIFa and adaptive scheduling, conform the POSIX1 003.4 specifications. There are 14 kemel calls associated with these ser vices.
The makers claim that QNX is very stabie and robust, because the protection of memory blocks and OS-data-area's. The 32-bit architecture is extremely scaleable, down to a system with 256K of memory or less and is able to boot from ROM or connected network.
page 26 J.H.M. Lemmers Choosing a real-time operating system Chapter 5
For process-communication the kemel provides message-passing facilities. These facilities are blocking versions of SendO, ReceiveO and Reply(). Processes can request that messages be delivered in priority order and that process execution proceeds at the priority of the highest priority blocked process waiting for service. This message-driven priority mechanism avoids priority inversion problems. Server processes are forced to execute at the priority of the process they are serving and vet automatically have their priority appropriately boosted when a higher- priority process blocks on the busy server.
Further the kemel provides a system call which allows user-processes to conneet a handier within a sufficiently privileged user process to a particular interrupt vector within the kemel, The connected handier can be called by the kemel in response to physical interrupts. So developing resource managers is not functionally different from developing user-Ievel process.
The process-based file system and device managers create a flexible operating system, because it is easy to add new resource-managers Iike a file system supporting the PC-DOS-fiIe system. There are many resource drivers available, Iike E-IDE, SCSI drivers. ONX can run multiple networks simultaneously and all kind of networking and network-adapters cards are supported. Modules are available for Token Ring, TCP/IP and seriallinks, sound cards.
table 5·1 Examples performance ONX Interrupted process continues or Interrupt Interrupt handIer Interrupt handier driver process starts urs runs finishes execution oC1 ~ ~ ~
I I IL...------l
lil I ITs1 or liret Tint Til interrupt latency Tint interrupt processing time Ts1 scheduling latency ( if a driver process is started by the interrupt service routine, a scheduling is needed Tiret interrupt termination time ( if no changes occurred in the states of the processes, no scheduling is needed )
Processor Interrupt Interrupt Scheduling context latency termination latency switch 16Mbyte RAM and 1.2 time [ Jls ] [ Jls ] [ Jls ], GByte SCSI Disk [ Jls ] 60 MHz Pentium 11 4 5 66 MHz 486'1 6 5 33 MHz486~) 6 5 14 17 25 MHz486~1 8 7 18 22
1) source : Performance: http://www.qnx.com/productlperforrn.html 2) source : An architectural overview of QNX ([ 5-2 ])
There are three graphical user interfaces (GUI's) available: • Photon provides a Iight-weight GUl that requires a mere 256K of RAM • GWindows provides a medium-duty GUl and an open look (or motif) environment with modest RAM demands (2Mb for runtime + 1 app). • XWindows is available for the heavy-duty GUl requirements.
ONX supports a list of Intel-processors ( Pentium-80286) and list of bus-platforms ( PCI, VESA, VME and others ). For development of applications are Watcom C and Watcom C++ available.
Page 27 Chapter4 A reaI-time operating system J.H.M. Lemmers
5.3.2 VxWorks
VxWorks is a real-time operating system developed by WindRivers Systems. It has a close relation to UNIX and is based on a host-target development-environment. The host is used for program development and non-real-time applications, running UNIX or a PC-operating system. The target is running VxWorks and executes all real-time applications.
The VxWorks kernel is constructed at the host-system and equipped with only the requested functionality. The scaleable ··Host· micro-kemel can be less then 20K, (UNIX!~p ) dependable of the configurable kemel functionality. VxWorks is able to boot from a local disk, ROM or a network. The Netwerk micro-kemel offers a multitasking environment, preemptive and round- robin scheduling based on 256 priority figure 5·2 Host-target development-environment levels. Priority based preemptive scheduling is the default algorithm in VxWorks, but applications may optionaJly utilise round-robin selection as weil. External interrupts are given precedence over any task priority. Further VxWorks is extendible with multi-processors and virtual memory support.
For inter-task communication and coordination, message queues, pipes, sockets and semaphores are available. VxWorks uses one shared address space, creating the danger of access to unprotected memory. Priority of low priority tasks can be elevated, if it is causing priority inversion in a critical area.
The software is developed on the host-system. The next step is to download the software to the target. The host-system offers functionality to debug sourees and to view real-time behaviour. As development environment is offered editor/compiler/loader/debugger facilities or the integrated development environment Tornado, supporting C/C++ and diagnostic and analyse tooI. Another development tooI is the 'Wind Foundation Classes', supporting object-oriented development according to Booch. This tooi includes a class-library.
Wind River Systems, as said, also supplies Tornado, an integrated and graphical development environment for embedded applications. Tornado consists of three integrated components: • a set of powertul cross-development tools and utilities • the VxWorks run-time system • a range of host-target communications options. Tornado provides a developer graphical facilities to edit code, to compiIe C and C++ code, to debug and to inspeet all run-time objects and memory locations.
A shell is available as an optional task, providing access to the target system, using a serial- or network-Iink. Written and compiled software, after downloading to the target system, is available and functions can be executed as independent tasks.
Matlab's SJMULINK is able to create real-time programs tor execution under VxWorks. Furthermore SIMULINK provides a mechanism to download new parameter values to the executing program and facilities to display data.
VxWorks is suitable for many different target systems, by providing an environment independent trom the used hardware. A set of network protocols and techniques are supported. Numerous higher-level VxWorks facilities provide even higher abstractions of inter-task communications, including pipes, TCP/IP soekets and Remote Procedure Calls (RCPs).
page 28 J.H.M. Lemmers Choosing a reat-time operatlng system Chapter 5
5.3.3 VRTx
The VRTx-kemel family is developed by Microtech Research. VRTXlOS offers a choice of three compatible real-time kemels • VRTXsa kemel, a high-performance full-featured kemel • VRTX32 kemel • VRTXmc kemel, a real-time kemel specifically designed for microcontrollers, featuring minimal RAM and ROM. All VRTXmc and VRTX32 applications are upward compatible.
The kernels offer a high speed and deterministic response to time critical system calls. The microkernel services are preemptable meaning that almost no scheduling latency is imposed. The microkemel supports priority inheritance, meaning that kemels based on the microkemel are priority inversion-free, resulting in predictabie system behaviour.
VRTx provides preemptive, priority-based scheduling and optional round-robin scheduling, fixed size memory partitions. VRTXsa provides variabie size memory partitions. Furthermore VRTx supports the memory management of variabie and fixed-block memory allocation and provides a real-time clock. The kemel and the applications are ROMable.
The kernels offer a selection of inter-process communication and synchronisation mechanisms, including mailboxes, queues, event flags, semaphores and priority-inheritance mutexes.
The VRTx-kemels are modular extendible for networking, file and byte stream 110 and an embedded user interface shell. The SNX network module provides a real-time embedded streams engine, and provides users a wide range of protocols (for example TCP/IP, UDP/IP and a wide range of other protocols over a variety of physical interconnect media (Ethernet, serial lines, shared memory). Networking activities are handled by a task that runs at an user configurable priority. This allows the user to determine, whether other more time critical tasks should be processed at a higher priority than the networking activities.
Microtech supplies an integrated software development environment, consisting of a C/C++ compiler, linker, assembler, debuggers and a real-time operating system. This compiler is very weil supported and guaranteed. .
Page 29 Chapter 4 A reaI-time operating system J.H.M. Lemmers
5.3.4 iRMX
Intel started In 1970 with the development of iRMX, a real-time operating system. The present version is iRMX for windows, a ROMable, multitasking and multi-user 32-bit version, optimised for the Intel386 family of microprocessors.
The nucleus is capable of processing tasks up to 256 priority levels. 5cheduling is preemptive priority-based and/or round-robin based. The memory management provides dynamic memory allocation and a set of security-services, like memory segment length protection, stack overflow detection and access right protection.
Furthermore there are several facilities to support inter-task communication, mutual exclusion and synchronisation, Iike mailboxes, semaphores and regions.
iRMX has the capability to run 005 and Windows 3.1 as low~st priority task under iRMX. iRMX-applications have the possibility to call D05IWindows system calls. Further is Windows' Dynamic Data Exchange (DOE) supported, providing the ability to continuously pass data back and forth between the real-time task and Windows programs. These facilities makes it possible to combine real-time applications with a large set of Windows programs, Iike Matlab, databases and spreadsheets.
iRMX has the ability to run real-time applications on a PC and a range of industrialised PC compatible hardware platforms and supports. iRMX requires minimum 4 Mbytes of RAM and minimum 40 Mbytes for development.
Included with iRMX is a development tooi containing for example a 32-bit C-compiler, a PUM compiler, a A5M386 assembler, 50ft5cope debugger and a set ot Iibraries. Further Microsoft C/C++ version 7.0 and Watcom C/C++ version 9.5 are usabie.
5.3.5 Other real-time operating systems
According to Internet sources there are more then 25 commercial real-time operating system available. I want to mention the following operating systems: • 059/059000 Microware's 059 is a real-time system, totally pointed to Mc68000 processors. 059 operates already a long time and has proven his capability. 059000 is a portable version of 059, supporting 80386/486 and Pentium processors. However the 059 suplier dissuade 059000, because it has not proven to be reliable. • p505 • Chorus Chorus is a French real-time micro-kemel, for building open, distributed real-time embedded systems, supporting a wide set of target architectures.
page 30 J.H.M. Lemmers Chooslng a reaI-time operatlng system Chapter 5
5.4 Evaluation
The maln conclusion of this research is that there is no main real-time operating system configuration, suitable for all real-time application. The characteristics of real-time applications differ to much. The developers of real-time operating systems side-step this property by building high modular operating system, 50 the functionality is highly adjustable.
Furthennore a conclusion of this research is that there is no best operating system. All researched operating system have proofed their quality in practice and are weil documented. The performance of the real-time operating systems does not vary much. The differences between the real-time operating systems are in the area of development tools, support by local suppliers, the price, the level of offered guarantees for the compiler, and a host-target or a stand-alone configuration.
This research shows a conflict between at one side performance and predictability and on the other side functionality. Increasing functionality results in decreased performance and predictability. The challenge for real-time operating system developers is to create an operating system, which provides high predictability and performance. But the operating system has to provide functionality exactly adjusted to the wide range of requirements. Most developers choose for a functional stripped kemel, extendible with modules providing the requested functionality.
New areas of development are the graphic development environment, including editors, compilers and debug facilities. These debug facilities enables the developer to observe and control a real-time application, input and output values and the operating system operations.
For the measurement and control group I want to recommend VxWorks. The advantages of VxWorks are: • VxWorks provides the graphical development environment Tornado • Local suppliers are present, able to give service • Matlab's real-time tooibox is abIe to generate code for VxWorks • ObjectTeam OMT is able to generate code for VxWorks • VxWorks is already used at the TUE. A major disadvantage of VxWorks is the high cost, comparing to the other real-time operating systems.
Page 31 Chapter 4 A real-time operating system J.H.M. Lemmers
5.5 References
Books: [ 5-1] H.M. Deitel Operating Systems, second edition Addison-Wesley Publishing Company, 1990, ISBN 0-201-50939-3
Artic/es: [ 5-2 ] Dan Hildebrand, QNX software Systems Ltd. An Architectural overview of QNX The Proceedings of the UNIX Workshop on micro-kemels & other kemel architecture, Seattle, April, 1992 [5-3] Temunao Soneoka, Aaru Oizumi and Koichi Suda Highly multi-tasking real-time systems and their evaluation Proceedings real-time systems symposium, 1993 [ 5-4] Tyler Sperry Buyers guide : Real-Time Operating Systems : Let the buyer be aware Embedded Systems Programming, Product New, Summer 1995 [ 5-5] Tyler Sperry Buyers guide : Choosing a Real-Time Operating system Embedded Systems Programming, Product New, Summer 1994 [ 5-6] Sherrie Van Tyle A Designers Guide To Real-Time Operating Systems Electronic Design, august 21, 1995, page 75
page 32 J.H.M. Lemmers Structured development of real-time software Chapter 6
6. Structured development of real-time software
6.1 Introduction
In chapter 3 the term software engineering is introduced. This chapter explains aspects of real time software engineering, namely development methods (paragraph 6.2), software manage ment ( paragraph 6.3) and software Iifecycles (paragraph 6.4). Special attention is paid to real time aspects of software development (paragraph 6.6), functional and object oriented methodo logies (paragraph 6.S) and verification and validation (paragraph 6.7).
Furthermore a survey of development methods is included in paragraph 6.8.
6.2 Software development methods
The purpose of a development method is supporting the designer in developing, analysing, designing and recording a software application. all focused on developing modifiable. efficient, reliable and understandable software. with high quality. within the right time-period and low cost.
To describe the architecture of a software system an engineer can use a natura/ or a forma/, abstract language. A natural language leads to unclear descriptions, which can be explained in different ways. Furthermore a naturallanguage is for a computer very difficult to understand. Therefore systems methodologies are developed.
A methodology provides facilities to record specifications and the architecture according to a set of modeis, rules and notation-techniques. Clear and precise descriptions, symbolic representations of the subject matter. are essential for all our understanding, analysis and communication. The concepts of the description must fit the concepts the developer wants to describe and the syntax must be convenient with respect of ease of making, ease of inter pretation and ease of reasoning. Understanding is based on a fixed predefined interpretation model, usually mathematically defined.
The software community has evolved dozens of different design methods. Despite their differences, all of these methods have elements in common. Specially, each method includes the following • notation the language for expressing each model • process the activities leading to the orderly construction of system's model • tools eliminating the tedium of model building and enforcing rules about the models themselves, 50 that errors and inconsistencies can be exposed.
page 33 J.H.M. Lemmers Structured development of real-tlme software Chapter6
The requirements of a formal language are: •A specification must be easily understandable by man. • The specifications must be complete, containing all the information required by the inter pretation model. • The specifications should be unambiguousand should allow one and only one interpretation, independent of the reader. • The specifications must be verifiable and analysable by a computer, through tools that can provide information on consistency, completeness, dead loek analysis, simulation and execution times. • The specifications should be consistent. Using different terms for one and the same object mayalso lead to confliets •A specification should be traceable. The origin of each and every requirement must be traceable.
The advantages of the use of a formallanguage are that the human being is forced by the presentation rules to fill in all the significant details required by the interpretation model and that the specification can be used for prototyping and to produce program code.
A structured method can make use of the next principles : • Abstraction Abstraction means ignoring some aspects of a phenomenon by concentrate on the essential features in order to describe and understand others more clearly. Details are removed, but the whole system is considered. • Encapsulation or information hiding Encapsulation is hiding the details of the implementation, so that these parts are not accessible for and not know to other modules. Communication with the object is only possible using the user-interface of the object. • Modularity In order to increase the developers insight and comprehensibility and the reusability of software the system is decomposed into a number of modules, with a minimum of interfacing • Aggregation and partitioning The process of lumping components together to form a whole is called aggregation. The opposite process of decomposing a whole into parts is called partitioning or decomposition. • Inheritance Inheritance is arelation between a number of classes, where one class, the sub-c1ass, the structure and behaviour inherits from an other class, the super-class. The sub-c1ass is a specialisation of the super-class.
page 34 J.H.M. Lemmers Structured development of reaI-time software Chapter 6
6.3 Software management
A design and development activity is c1early an activity of a group of people working more or less towards a çommon goal. Thus there is a need to have an efficient organisation of the team with clear goals and division of responsibilities among the individuals.
Planning the project is the very first step to be undertaken, resulting in the project plan. The project plan provides a clear picture of the project to both the customers and the project team. Planning is not a one-shot activity. Rather, it is highly dynamic in nature, because a number of properties will not be sufficiently weil understood until the analysis phase has ended.
Once the project plan has been drawn up and the project has started, its execution must be controlled. The next five entities require continuous attention: • time How do we assess progress toward the projeet's goals. Usually, same phased approach is followed, which aims to provide management with a means to measure and control progress. The time needed to build a system is related to the size of the system and thus to the total manpower required. Larger systems simply require more time to develop, although we try to shorten development by allocating more people. However, If more people are involved, more time will be needed for coordination and communication. • information How do we handle the vast number of documents that are produced in the course of a project. Besides technica! and user documentation, this also includes documentation on the project itself. Documentation concerning the project includes the.current state of affairs, changes that have been agreed upon and decisions that have been made. • organisation How do we organise the project team and coordinate the activities of team members. All members of the development team must know what their role in the team is and under stand what is expected of them. It is very important that these expectations are clear to all peopJe involved. • quality How do we define and assess quality requirements for both the development process and the resulting product. It is not enough if a product is technical correct. A customer wants the system to fit their real needs. • money How do we estimate the cost of a project. Controlling expenses largely means controlling labour cast. The cost of hardware and tools can usually be estimated quite precisely early on the project and are usually much less of an issue than personnel costs. Estimating the cost of software thus means that we must estimate the manpower required to build the software.
page 35 J.H.M. Lemmers Structured development of reaI-time software Chapter6
6.4 Software Iife-cycle
A software development process is based on a strategy. This strategy must include clearly identifiable milestones to control progress. .. , \ \ One of those strategies is the waterfall-model. The I I development-process is divided in horizontallayers and is ,, developed layer by layer, using early results as start-point for , the next activities. Requisite for passing to a new phase is , , that the preceding is closed and its products validated at a .. , formal review. The phases, which are sequentially passed, \ , are: I I • analysis ,, • design , , , • implementation .. , • testing \ • usage and maintenance \ I ,I The waterfall model provides distinct milestones and it ,, highlights various necessary stages in software system , , development (see figure 6-1). However, the model bears little resemblance to designers working-methods. Further the waterfall model does not offer a good feedback. If a project has a very huge size or the requirements are high or un known materials or techniques are used, this model can result in a very late discovery that the project-demand can not be satisfied.
Another. mo.d~1 is ~he incremental model. Fir~t t.he .s?ftware figure 6-1 The waterfall model system IS dlvlded In smaller part. Every part IS Indlvldually worked out from specifications to implementation and testing, using for example the waterfall strategy. Afterwards is proceeded with the next part (see figure 6-2). This model provides a very good feedback, 50 developers are capable to check if the requirements will be satisfied. This model is very suitable for object-oriented techniques.
Part 2 Part 3 Part 2 ...... ------'----4 --+1------..... Part 1 I Part 1 flgure 6-2 The incremental model
page 36 J.H.M. Lemmers Structured deveJopment of reaJ-tlme software Chapter 6
Prototyping is used if it is not sufficient to take the existing situation as the one and only starting point for setting up software requirements, because the user can not express his requirements precisely or the results are uncertain. By creating prototypes the developers and the users can get a good impression of what the future system wiJl provide them with (see figure 6-3).
In the spiral model (see figure 6-4) the most difficult parts or the parts that have the highest risks, with respect to a successful completion of the project, are aften tackled first. In the spiral model, each con- vol ution of the spiral gives rise to the following activities: • identifying the sub-problem which has the highest risk associated with it • finding a solution for that problem.
figure 6-3 The prototyping model
Evaluate altematives. indentify and resolve risks
th::velijprr;c :~t :n Jt~ vörlous gu:se.>
Plan next phase Develop, verify next level product figure 6-4 The spiral model
page 37 J.H.M. Lemmers Structured development of real·time software Chapter6
6.5 Functional versus object oriented methods
In functional oriented methodsthe system representation is based on a collection of processes, each performing a function (or a set of functions). Each function is part of the overall purpose of the system itself so that the system architecture and system functionality is localised around functions. The first step using these methods is to specify what the system must do. The fol· lowing step is to determine how it will be implemented.
In object oriented methodsthe system representation is based on the description of the objects and the operations applied on those objects. The first step is localising the system-information around the objects, after which the dynamic and functional aspects are examined.
An object is a model, an abstract description of a rea! world entity, only including the relevant information. The information consists of object-data and functions working on that data. The object should act as a black box hiding the data and allowing access only by means of operations.
A class is a template, a description, a pattern or a 'blueprint' of a category or a collection of very similar items. It is a collection of objects with equal structure and behaviour. A class is used to create object instances.
Object oriented methods use the following techniques: • inheritance A class can inherit structure and behaviour from other classes. The sub-class is a specialisation of the mother-class. • abstraction Abstraction is aiming the attention to essential parts of a object. The essential parts of an object depend on the point of view. • encapsulation Encapsulation, or information hiding, means hiding the internal structure of an object. Communication with a object is only possible by way of controlled interfaces.
The intention of object-oriented design is to create an as good as possible description of the real world, in contrast with functional oriented design, where the emphasis is put on functionality of the system to develop. Furthermore object oriented methods show full advantage using an iterative or spi ral strategy, in contrast with functional oriented methods, which lean on the waterfall strategy.
The last years object-oriented methods are announced as a revolution and the popularity of object oriented design is increased. The methodology promises: • more reusability of parts of the software-system • better management of the size and complexity of sottware-systems • increasing robustness • improvement of the software development • increasing development speed.
Object oriented methods are based on the real-world entities and the functional methods are based on what the system has to do. The first intuitive step is describing a system according to the functions it shall accomplish. At least user requirements will always be functional oriented. So in the early development phases the functional methods are easier to use then the object methods. Most developers, which change from functional oriented to object oriented design, have difficulties with not looking first at what the system has to do, but to look what objects are related to the system.
page 38 J.H.M. Lemmers Structured development of reaI-time software ChapterS
The leading principles of object oriented approaches are essentially the same as those that form the basis of a modular design. Modularity has a great impact on software testability and maintainability. Object oriented methods can therefore be considered inherently more appropriate to support modularity, resulting in more stabie systems, less liable to changes. Further the strong modularity and weil defined interfacing routines contribute to the creation of a Iibrary of reusable objects. This results in time-savings in future projects.
Because object oriented methodologies are also based on the principles of information hiding, entrances to variables is only possible through controlled functions. The control on operations and parameters is much better and the coupling between software parts is very loose, com paring with functional oriented techniques. These advantages result in increasing modifiability.
Object-oriented methodologies will cause less interface-problems, because objects, which passes the same interface, are easy to exchange. Furthermore the system-borders are easy to extend by removing or including objects in the system. Changing the interfacing of functional oriented designs results in far reaching modifications, because the system-borders are related to different system-parts.
If an object oriented methodology is used, it is strongly recommended to use an object oriented program language (OOPL), although it is possible to swap strategy during the design-irrple mentation step. Object oriented methods have straight rules and incJude some implementation techniques. This results in decreasing errors, like wrong use of functions or variables and invalid initialis ation.
High expectations are created for object oriented methods, but these methods cannot fulfil these expectations completely. During the analyse phase and the beginning of design phase functional design function oriented methods are stronger, but in the implementation-, testing and maintenance- phase, object oriented methods are much stronger. This results in time savings and more stabie software.
But do not forget that object oriented design is no revolution but an evolution. The quality of a software-system is still provided by the analysis, design and implementations ski 115 of the designer. And object oriented design needs an other way of thinking. So changing from func tional oriented methods to object oriented methads is not easy and the advantages wil! not show up immediately.
page 39 J.H.M. Lemmers Structured development of reaI-time software Chapter 6
6.6 Real-time aspects of structured software-development
6.6.1 Handling events
There are several ways to process events. A software system can be build like a big looping structure, that polls the event entry's, if needed extended with interrupt-handlers. Every loop the system carries out a poll and pieces ot concurrent processes. A disadvantage of such a structure is the large overhead and complex design-architecture.
An altemative is a multitasking kernel or operating system, which allows the designer to develop independent tasks which use interrupts to respond to external events. Designer work decreases and is replaced by a general mechanism. This mechanism provides a environment for tasks to run independent and simultaneous.
A timing constraint imposes a temporal restrietion on a system or it users. Timing constraints may be classitied by three types of tempora' restriction: • Maximum no more than t units of time may elapse between the occurrence of one event and the occurrence of another. • Minimum No less than t units of time may elapse between the occurrence of one event and the occurrence of another. • Durational An event must occur before t units of time Most methodologies use finite state machines and the timing constraints are modelled by the system's present state and the stimulus that has arrived. A timer is started and generates an event after the particular time is expired. As aresuit to the generated timer event, the state machine: • steps into a error-state, if a failure occurs ( tor example a maximum time constraint) • steps to the next state ( a minimum time constraint) • ignores the timer event if it is not relevant anymore.
page 40 J.H.M. Lemmers Structured development of real-time software Chapter6
6.6.2 Dynamic behaviour
When analysing a real-time system, one should provide both a description of the dynamics of ,.the environment where the system will be embedded, as weil as of the desired behaviour of the . automation system to be developed. A specification method suited for real-time applications should allow the specification of the following temporal aspects: • temporal ordering among different activities • concurrency • synchronisation • periodicity • deadlines and maximal/minimal response and execution times • time-out, reaction to exceptions.
There are several techniques to describe dynamic and real-time behaviour : • Scenarios Scenarios are used to describe events and the order of events between system-parts. Scenarios are mainly used for specification or report of system behaviour. • State-diagram A state transition diagram describes dynamic behaviour of a system-part in terms of a finite number of discrete states, conditions for a state-step and actions related to a state. State-diagrams focus on the external interaction sequences and completely describes the relationship between sequences of inputs and sequences of output. The state-diagram is used to describe how the behaviour of a system-part will be accomplished. Almost every methodology uses it's own techniques with different forms and different names, but the essence of the used techniques are equal to the above mentioned techniques.
Further a real-time method has to provide facilities to control concurrency and inter-process communication and to describe the external world- and system-interfaces. To tie up the time constraints is only useful if the architecture produced is checked for the time-constraints to be met.
page 41 J.H.M. Lemmers Structured development of reaI-time software Chapter 6
6.7 Verificatien and validatien
To achieve the requested quality it is important to check that the system definitions produèed at the various stages represent a system with the desired quality and the concrete system itself is a correct implementation. Furthermore as mentioned in paragraph 3.4, for developers it is very valuable to determine in an early phase of the development process, if the architecture is correct and meets the requirements. This involves reviewing and testing.
To detect errors and other shortcomings developers have to verify and validate the developed system. Verification means checking if the system meets its requirements ( are we building the system right). Verification tries to assess the correctness of the transition to a next phase, in cluding detection of all pathological behaviour pattems to be avoided ( for example dea dlocks, dynamic errors and unspecified receptions). Validation means checking if the system meets the user's requirements (are we building the right system), proofing that an architecture provides the service it was designed for.
The following three techniques for verification and validation are available: • review of produced documentation and code by members of the development team • testing • verification and validation by software tools.
There are two distinct aspects to test • the functionality Up to a point the functionality can be tested by means of a simulation tooi executing the functional design. Functionality test does not depend on a particular implementation, but can be achieved with any implementation that is faithful to the functional design. The purposes of functionality testing are Iisted below: 1.. verification of the functional design against functional requirements, by the develo pers 2. detection of possible internal inconsistencies and errors in the functional design by software tools or by the developers 3. validation of the functional design against the users and owners needs by users and by the developers. • the implementation The scope of implementation testing is more limited. lts purposes are as follows: 1. verification of the functionality of the implementation against the functional design, done by developers or by computer 2. verification of the non-functional properties of the implementation against the non functional requirements, by developers or by computer. This is hard to realise.
In many practical (or traditional) cases the functionality is checked for the first time in the implementation, so the functionality and the implementation are tested at the same time.
The ideal situation occursif the developers are able to establish if the system designed will satisfy the requirements at an early stage. So testing the system designed without running the software on the hardware. In this situation the developers are able to determine in a very early stage if the requirements will be satisfied, even when the used hardware is not available.
In this case a tooi must be available, which simulates the system, including the hardware and the software. To calculate the system-performance and if the-constraints are met, implemen tation and system-configuration information must be available. Important points are implemen tation-aspects Iike capacity, interrupts handling, priority handling, task synchronisation and communication and a complete description of the hardware must be available. For every piece of software it must be established how much time it takes to execute this software and in what order it will be executed. An altemative is to record for pieces of software how long is wil! take to execute. Now the simulation tooI is able to execute the system designed and to establish (roughly) if the capacity of the system is satisfying.
page 42 lH.M. Lemmers Structured development of real-time software Chapter 6
6.8 Survey of development methods
The development methods discussed in this survey are selected on popularity and acceptance in the industry and academic world. They are weil documented and weil supported by CASE tools or especially created for development of real-time applications. Moreover special interests are shown tor object oriented methodologies.
') The methods are judged on the quality of the following points: • suitability for real-time applications and support of dynamic behaviour • level of support for the life;cycle • easiness to read, level of detail, easiness to leam and easiness to use of used techniques and models • guidelines for development-process • smooth and logical development path • completeness • consistency • popularity • availability of documentation • availability of CASE-tools supporting the method
I want to remark that the used diagrams are only mentioned for iIIustration. The purpose of these diagrams is to give the reader insight in the matter. Appendix Band appendix C contain a summary of the following development methodologies. Chapter 7 contains more information about CASE-tools.
page 43 J.H.M. Lemmers Structured development of real-tlme software Chapter (l
6.8.1 Structured Analysis and Structured Design (SA/SO) by Ward and Mellor
SAISD is a functional oriented method, introduced by Ward en Mellor In [ 6-12]. 5A15D is based on the Yourdon-school, extended with real-time facilities.
During the analysis phase, Data Flow Diagran1s , a data dictionary, state transition diagrams and entity-relationship diagrams are used to logically describe a system: • Data flow diagrams (DFD) are the main focus of SAISD and model the transformations of data, flowing through the system. A data flow diagram consists of processes, data flows, actors and data stores. SAl5D recursively divides complex processes into sub-diagrams, until many small processes are left that are easy to implement. When the resulting processes are simpte enough, the docomposition stops and a process specification is written for each lowest-Ievel process. • The data dictionatycontains details missing in the data flow diagrams. The data dictionary defines data flows and data stores and the meaning of various names. • State transition diagrams (STD)model time dependent behaviour and forces the designer to view and represent the system in terms of discrete state. • Entity-Re/ationship diagrams (ER) highlight relationships between data stores that otherwise would only be seen in the process specifications. Each ER data element corresponds to one data flow diagram data store.
.0------ . ., , ,, , \ , \ ~ \ ['OatafIOW 2 \ I , \ Oalaflow4 , \ t \ t \ , \ , ,, , ,. , , 00 ..... _------figure 6-5 The context diagram and the first level DFD
The first step in the analysis-phase is recording the essential model, which consists of two parts: • the environmental model describing the environment in which the system operates. This model has two parts: the context diagram, a description of the boundary between the system and the environment, showing the interfaces between the two parts and theevent /ist, a description of the events that occur in the environment to which the system must respond. • the behavioural model describing the required behaviour of the system in response to events in environment, using two connected schemes. The transformation scheme denotes graphically the layout of the transformations that operate on flows that cross the system boundary and the active portion of the system that responds to events that occur in the environment. The data schema denotes graphically the layout of information that must be remembered by the system for it to operate correctly.
page 44 J.H.M. Lemmers Structured development of real-tlme software Chapter 6
The essential model is created in the following steps: a) Draw the context diagram. b) Create a list of external events that must be handled by the system. c) Draw DFDs for the system from the top down. Entity-relationship diagrams are used to help assist in stored data partitioning. d) Create a data dictionary for the data flows, data stores and control flows e) Draw state-transition diagrams for each control bubble f) write textual speci1ications for each primitive bubble in the essential model's DFD hierarchy.
figure 6·6 Example data flow diagram SAISD specification techniques
The environment and behavioural model are described using above mentioned techniques. The priority order in the analysis phase is the Data Flow Diagram first, followed by the state transition diagrams, and then the entity relationship diagrams, This is reverse of 00 approaches. UneOf Enable 'Qlange boItIe size' Dsable 'RIl bol1Ie' In the essential model all implementation issues are excluded. The implementation technology is added during the design phase added in the impJementation mode/s The BoltIe in P09tia1 Enable 'FiD bcltIe' following steps are followed to create the implementations model: a) Processing environment: allocate the essential model to processors by deriving the new DFDs, state transition diagrams and entity-relationship diagrams from the essential model and splitting these between processors when necessary. b) Allocate tasks within each processor: Make BolIIe IQ in pa6itia1 design decisions that will potentially impose 1...-_---1 sequences on logically concurrent data .. , transformations. figure 6·7 Example state transItion diagram c) Software environment: model the role that system utilities play in the implementation (for example device handiers) d) Code organisation: draw structure charts to partition the high-level design into hierarchical coding units and create structure charts.
page 45 J.H.M. Lemmers Structured development of reaI-time software Chapter6
Description of Description of the boundary l~ the environment Context diagram that separates the I), Envlronmental behaviour system from its environment k model in which Description ofextemal events k the system Event list in the environment to which I~ operates the system must respond j;; Transformation Description of the trans- Description of schema and formations the system In Behavioural behaviour in specifics makes in respond to events model response to events in Data schema Description of the information environment and the system must have specifics in order to respond .~ ., k.'k-"· '".. " ",;;.«j;;': flgure 6-8 Essential modellayout
SAISD is a weil known design method and the used specification techniques are easy readabIe. Further programmers have tended to think in terms of functions, so data flow based methodologies are easier to leam.
In [6-6] is mentioned that SAISD design has a clearly-defined system boundary, across which software procedures communicate with the real world. The structure of a SAISD design is derived in the system boundary, so moditying the system-boundary can result in extensive work in all the connected architect-parts. It is much easier to extend an object-oriented design, because mostly the boundary is represented by objects, which are easily to modity or to exchange, as long the object-interface stays equa\. Moreover object oriented design forces a streng modularity, so that system-parts.are less interwoven with each other.
In the article [ 6-28] are several disadvantages of SAISD mentioned: changes in the problem domain results in large amount of work to update the analyse and implementation model, the support for real-time aspects, Iike time-constraints, is superficial, there are no facilities to reuse software-parts and the methodology requires much documentation to specify dataflows and bottom level transformations.
An advantage of SAISD is the wide support by CASE-tools.
page 46 J.H.M. Lemmers Structured development of real-tlme software Chapter 6
6.8.2 Specificatien and Descriptien Language (SOL)
Another real-time design methodology is Specification and Description Language(SOL) in combination with Message Sequence Chart(MSC).
SOL is originally developed and widely used for specification of telecommunication system, however the method is also suitable for process control systems, soft and hard real-time. MSC is used to describe the information-exchange. SOL and MSC have both a graphical representation and a phrase representation and both are totally equivalent.
I ICharrel_5 Channel_2 I BIoclc21
~hanneL11 ChanneL4 I Block_1 I 3 ChanneL3 I BIOCk_ 1
figure a Block diagram figure b Process diagram figure 6-9 Examples SDL-diagrams
SOL and MSC use a top-down approach. A system firstly is described in the hierarchy diagram by a refinement of bloeks, processes and procedures. The system interacts with its environment through channels and is refined into blocks interconnected through channels. Blocks may be refined into more blocks.
Processes in the system and the environment communicate with each other, using asynchronous message-exchange. Each process instance consists of an individual FIFO (first in, first-out) input queue, to receive these messages, and an extended finite state machine with a 'sequential behaviour defined by a process graph. The finite state machine fetches signals from the input port. For each signal it pertorms one transition which will take a short but undefined time.
Signals and data are defined in special symbols called declarations placed at any level in the hierarchy, according to their required visibility and accessibility. The connections, between the structuring entities making up the system architecture, are described in interconnection diagrams.
Each SOL process is described by a finite state machine (FSM). An FSM defines the reaction of a process to signals depending on its intemal state. The actions pertormed during the transitions are described by means of signal receptions, signal output, tasks (corresponding to data manipulation), decisions (switch within a transition), procedure calls, timer manipulations (set, reset and expiration), process instantiations and loops.
The MSC notation is used as specification language to describe sequences of signal exchanges between SOL entities. MSCs are used in parallel with the definition of the system architecture to describe possible seenarios, describing what the system to implement should do. These definitions are put in a Scenario diagram, a hierarchy of scenarios. Scenarios are progressively decomposed into terminal scenarios. An MSC can contain additional symbols such as state, timer set, timer reset, time-out, start, stop or procedure caU.
page 47 J.H.M. Lemmers Structured development of real-tlme software Chapter 6
A MSC description should be consistent with the SOL description: hierarchies of MSCs are based on the SOL hierarchy and each MSC may refer to SOL objects such as processes, signais, timers and procedures.
The followed strategy is: 1. MSC is used to describe the functional specification, what the system to implement should do. 2. The developers tie up scenarios for small pieces of the system, which can be viewed as black boxes. MSCs are describing the external behaviour of the black boxes. 3. SOL is used to describe the first level of decomposition. The black boxes are turned into grey boxes. because the contents of the boxes are defined. 4. The steps 2 and 3 are iterative repeated until the SOL process level is reached.
Verilog claims that the SOL and MSC combination has the following advantages: • a smaU gap and a strong link between specification and implementation • the impact of changes is assessed by looking at the MSC.
Verilog's ObjectGEOOE and Telelogic's SOTare CASE-toals for real-time software development. using SOL and MSC.
mscX Process_1 Process_2 Process 3 I II II I
message_l
message_2
message_3
message_4
message_S
flgure 6-10 Example MSC scenario
page 48 J.H.M. Lemmers Structured development of real-time software Chapter 6
6.8.3 Object Modeling Technique (OMT) by Rumbaugh and others
OMT is introduced in 1991 by J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy and W. Lorensen in the book 'Object-Oriented Modeling and Design' ([ 6-6] ). The method covers all software-development phases and is based on traditional techniques. Further OMT is one of the best known and weil documented methodologies.
OMT knows three phases: • Analysls In the analysis-phase three models are develop~d, the object-model, the dynamic-model and the functional-model.
The object model (see figure 6-11) describes the static structure and relations of all objects and classes in the system. The object model uses a extensive set of notations to record the object-associations. This model is extended with a data dictionary. The dynamic modeldescribes the events, the event-order, the states and actions existing inside objects, between objects. The Functional modeldescribes the data transformations, using Data Flow Diagrams (DFD). This model describes what the system is doing, without describing how it is done. The three modeIs are strongly related. • System design the architecture is divided in sub-systems in connection, concurrency and the shape and management of shared recourses is tied up. Further the implementation (event driven, procedure driven, concurrent) of software control is chosen. • Object design the architecture, produced in the analysis-phase, is worked out in more detail as preparation for the implementation. In object design the three modeIs used in the analyse phase are further extended to benefit inheritance, to describe chosen implementation algorithms, to implement the chosen software control and associations.
Operator tests product
19ives
Input
SeCParamt SeCParem2
~r 0 Controller controls Process makes Product has Quality ~ SeCParaml \.
SeCParam2 Real-bme setpoints communicates
~ Interface /, I V MachinePartl MachinePartl MachinePart2
Act_data Ac,-data Ac,-data ) ) ) flgure 6-11 Example OMT object model
page 49 J.H.M. Lemmers Structured development of reaI-time software Chapter 6
The analysis phase is composed of the following steps: 1. Write an initial description of the problem. 2. Build an object model using an object model diagram and data dictionary, by identifying objects and classes, preparing a data dictionary and identifying associations between objects, object attributes and link attributes. 3. Develop a dynamic model using state diagrams and event flow diagrams, by preparing scenarios of typical interactien sequences, identifying events between objects, preparing an event trace and constructing a state diagram for each cIass that has significant dynamic behaviour. 4. Construct a functional model using data flow diagrams.. 5. Iterate and refine the three modeIs.
The object design process is composed of the following steps: 1. Obtain operations for the object model. 2. Design algorithms for these eperations 3. Optimise access paths to data 4. Implement software control 5. Refine class structure to increase inheritance 6. Design implementation of associations 7. Determine the exact representation'into modules 8. Package classes and associations into modules.
OMT has no facilities for an object-library to stimulate reuse of objects and does not support project- and management aspects. Another disadvantage, especially for large systems, is the shortage to break up the system in smaller sub-systems.
In the article [ 6-19] is mentioned that OMT is equipped with particularly rich and detailed data and state-transition modeis. Further it has many useful guidelines for creating these models and implementing them in a variety ot programming languages. As point of criticism is mentioned that OMT does not include any design modeis, available in other approaches. Further the treatment of process results in a vague description how the three representations are resolved and integrated as methods.
In article [ 6-26] is mentioned that real-time elements are not explicitly addressed in any way and the diagramming notation is not suitable tor brainstorming.
Article [ 6-13 ] is a report of the usage of OMT tor real-time systems. The authors extended the OMT methods by including the time constraints in the scenarios, the event trace diagrams and the state modeis, They conclude that the extensions results in an effective means for applying OMT to real-time applications.
The authors [ 6-15] used OMT for developing an application. They have learned the following lessons: • OMT clearly identifies objects, associations, aggregations and inheritance with a minimum amount when compared to ether object-oriented approaches. • OMT only covers a partial development cycle. It does not address issues related to software testing, verification and validation or maintenance • OMT does not prevent a solution-oriented model within the requirement model • The object model requires several passes to achieve optimum representation • Sometimes one object at a particular state in its dynamic model would require a response from another model. OMT dees not provide for these interactions between dynamic modeis. • The developer needs to identify all or most of the attributes, associations and aggregations in the analysis phase. Other object-oriented approaches allow creation of the data object as you recursively progress through requirements analysis. These approaches allow the analyst to develop the object requirements or data objects at any time.
OMT is supported by the following set of CASE·tools: • LOV/OMT by Verilog • ObjectTeam OMT by Cadre Technologies
page 50 J.H.M. Lemmers Structured development of reaI-time software Chapter 6
6.8.4 Object-Oriented Design (000) by Booch
000, developed by Grady Booch, is one of the earliest methods and weil supported. The method is described in [ 6-1 J. 000 is not based on the traditional waterfalJ.:strategy but uses a life cycle existing out of the phases analysis, design, evolution and modification. The accent is put on the design phase. It is possible to use a front-end method to execute the analysis-phase.
The 000 method describes the application domain from 2 views: the logical structure and the physical structure of the system. The logical view of a system serves to describe the existence and meaning of the key Logical model abstractions and mechanisms that Object structure farm the problem space or that define the systems architecture. The physical Module architecture model of a system describes the Physical model concrete software and hardware Process architecture composition of the system's context or implementation. figure 6-12 The models of 000
For both structures the static and dynamic properties are described. 000 is equipped with six diagrams for these approaches: the class and object diagram, the dynamic state diagram, the object scenario diagram and various graphical techniques to describe the physical structure of the system.
The following steps are to be followed in the design process: 1. Oefine the problem (a) State the problem in a single sentence. (b) As 000 does not include an analysis or requirements method, this step should be accomplished using another method. 2. Oevelop an informal strategy for the problem domain (a) State the informal strategy in the form of a single, grammatically correct paragraph. 3. Formalise the strategy by: (a) identifying the objects and their attributes. Create a list that includes the object, whether it is part of the problem space or solution space and assign identifying attributes to objects. (b) identifying operations on the objects. Create a list of options similar to the list of objects. add an additional column for the object which the operation acts on. Classify the operations of interest as 'selector', 'constructor', or 'iterator'. (c) Establish the interfaces among the objects and operations. Show the dependence of these units on each other. Add design decision program units. Draw Booch diagrams to show the software architecture. (d) Oecide on implementations of the objects and operations. Write the code for the highest Ievei program unit and use stepwise refinement to define the lower-Ievel program units. Recursively apply the 000 methodology to smaller units if necessary.
page 51 J.H.M. Lemmers Structured development of real-tlme software Chapter6
J -,... --, - Process '
"~ Sys~emControl ~; - , ...... 1 , -, - 1I , J ' ... -- • J ... -- , "'--, ~f:~~: ~ Timer ", .:.~ \", ( ~ Proeess ()", (- --_.,... g""'--, ""'-_\ 1
1 J ' ... • Process ." 1 ( ~ Controller \ .. ."., ..... -- flgure 6-13 Example system object diagram
OOD offers less support for the project-structure and the project-execution.
In article [ 6-19 ] is stated that, depending on your perspective, the Booch notation is either exceeding complete, or staggeringly complex. Although useful, the differentiation between class and object di.agram, flexible and friendly semantic but offers Iess holding for the designer. The way of notation includes a lot of information about relations, which results in a complex and not surveyable diagrams. Disadvantages are the absence of analysis modeIs and techniques and the lack of integration between the various design diagrams.
In article [ 6-28 ] it is mentioned as an advantage the encouragement of prototyping at the early stages in an unstructured creative way, which leads to an improvement in the integrity of the developed system. Disadvantages include the distance from implementation code and the lack of explicit real-time implementation support.
000 is widely supported by CASE -tools: • Paradigm Plus by Protosoft • ObjectMaker by Mark V Systems • System Architect by Poplin • MacAnalyst by Excel Software • Rational's Rose
page 52 J.H.M. Lemmers Structured devetopment of reat-time software ChapterS
6.8.5 Object oriented Analysis/Design (OOAlD) by ShlaerlMellor
OOA/D is developed by Sally Shlaer and Stephen J. Mellor. The method is based on traditional concepts and techniques out the Yourdon-school. The Shlaer/Mellor is a very strict method with strong formal aspects and many guidelines.
The method covers mainly the analysis-phase and uses three models (Information model, state model and process model). OOA/D knows the phases definition, analysis, design, realisation and controlling the system. Much attention is given to the analyse- and the design-phase. These phases are very weil connected and clear eheckpoints-products are present. The analyse- and design-phase consist of a set of activities: activltles anatysls • create a domain ehart The domain chart describes the different domains, a separate part of the system inhabited by a distinct set of objects that behave according to rules and policies, characteristic to the domain. • create an information model The information model describes for every (sub)domain the objects (or entities), the attri butes of the objects, and the relationships between objects. The objects and the relati01 ships are put together in the Information Structure Diagram (lSD), a variant of the Entity Relationship Diagram. • ereate the state model of objects and relations The STD eontains the potential states in the objects life cycle and the events that cause transitions form one state to another. Actions in the state modeIs will also become process in function models • create the Object Communication Model (OCM) The OCM describes the synchronous interactions between objects at the global system level. • create the Subsystem Communication Model (SCM) the SCM describes the asynchronous interaetions between state modeIs and external entities at the global system level. • create for every object the Action Data Flow Diagram (ADFD) The ADFD describes for every object-state, which data processing is performed and which events are generated. • create the Object Access Model (OAM) The OAM describes synchronic exchange of data between objects. • create the Subsystem Access Model (SAM) . the SAM describes synchronie exchange of data between subsystems. activities design . • create a inheritance diagram • create for every class the class diagram • create for every elass the class structure ehart
1.0VEN(V) • Oven ID powers,.... • Status " is installed in - Power Tube 10(R1) I' - Ught IO(R2) is powered by • Time ID , ,contains ,Ir
2. POWER TUBE(P) 3. L1GHT(L) • Tube 10 • Ught 10 • Wattage • Status • Status
figure 6-14 Example 1-minute microwave oven information model
page 53 J.H.M. Lemmers Structured development of real-tlme software Chapter6
In article [ 6-19 ] is mentioned that at first glance OOAlD appears similar to OMT, but it is actually much more complete and consistent. Very much attention is spent to the state model, 50 the method is strongly real-time oriented and ideal for engineering and real-timesystems, or for complex business systems with peer-to-peer relationships. Disadvantages are complex assortments of terms, models and diagrams. Some of its modelling concepts are unnecessary for simple business applications.
figure 6-15 Example 1-minute microwave oven Iife-cycle
In article[ 6-27] is mentioned that OOAlD does not support many object-oriented concepts in the analysis phase, including message passing, inheritance and encapsulation. The specif~ cations reflect a function modularity rather than a structural and behavioural modularity of modeis. This is the result of the strong relation to SAlSD-method.
The methods pays less attention to reusability of software parts. The included domain and subsystems concepts are making the method suitable for medium to large-sized projects.
OOAlD is one of the Iess popular and known methods, which makes that less dOQJmentation is available comparing to other methods. Nevertheless OOA/D is supported by a set of CASE tools: • ObjecTeam ShlaerlMellor by Cadre Technologies • Popkin Software Systems • IPSYS software
page 54 J.H.M. Lemmers Structured development of real-time software Chapter 6
6.8.6 Real-time Object Oriented Method (ROOM)
ROOM is a object-oriented methodology for development of real-time systems. The methodology has been driven by industrial experience at Bell-Northern Research.
The foundation of ROOM is a conceptual framework which .relates a domain-specific set of tructure modelling concepts and the activities of an iterative development process. The ROOM concepts are derived and classified on the basis Concurrency level of two complementary modelling paradigms: • Modelling dimensions Detail level There are three major modeling dimensions: '" structure containing communication and Behaviour containment relations of components '" behaviour flgure 6-16 Conceptual framework '" inheritance. • Abstraction levels: Separate modelling issues according to scope. Three such levels are identified in ROOM: '" System level has modelling concepts for dealing with the highest form of system organisation by layering, inspired by the OSI reference model. A layer provides a set of services to the entities in the layer above. For inter-Iayer relationships, the Iinkage between layers is done at discrete contact points between layers, added with service protocols. The bottom layers in avertical structure are provided by a run-time system. This system comprises a basic set of primitive services, which can be extended by user defined services. '" Concurrency level provides higher-level abstractions, such as communicating finite-state machines, actors, which model the particular form of concurrency specific to the domain. Actors have ports to communicate with the environment. To a port are included a protocol and a set of valid message types which are allowed to pass through the port. '" Detail level contains the fine-grained abstractions characteristic to the non-concurrent aspects of traditional programming languages including abstract data types and individual executable statements.
Bi"''',", =:Ll
Component Component Actor 1 Actor 2
Containing Actor flgure 6-17 Example concurrency level diagram
page 55 J.H.M. Lemmers Structured development of real-tlme software Chapter 6
ROOM uses an iterative development strategy, strongly in11uenced by reusability concerns. Every iterative step knows the next steps: 1. Checking the class Iibrary to see i1 an actor has already been de1ined that has a similar rele. 2. Assuming that new design work must be started, select a structural component (Iayer or actor). 3. If necessary, define the layering structure of the current component. A layer is often identified by the fact that the services which it provides appear to be 'primitive' at some application-specific level of abstraction. This usually means that it is used pervasively by the actors in the Jayer above. 4. Define the service access point classes and their protocols if layers are involved. 5. Decompose a layer or actor into a set of interacting actors with each component actor providing some weil defined function and encapsulating major data items such as states. 6. Define the protocol classes. . 7. Add high-level behaviour to the current component and 10 selected component actors. In the first stages, only rudimentary behaviour and detail may be required. 8. Verify the model. 9. Based on insight gained by execution, refine the model. 1O.At the point where the overall architecture is sutticiently refined, detailed data and behaviour can be added.
There is Iittle Iiterature on ROOM, 50 it was impossible to find objective test-reports of the ROOM methodology, only remarks made by the developers [ 6-24 ]. They mention as advantages: • the ROOM modeling concepts are domain specific and intuitive • the conceptual framework and choice of modeling abstractions eliminates discontinuities in the development process • the development process is highly iterative, computer based and supports early execution.
The CASE-tooi ObjecTime made by ObjecTime (Northern Telecom) supports ROOM.
page 56 lH.M. Lemmers Structured development of real-time software Chapter6
6.8.7 Object Oriented Analyse/Design (OOA/OOD) by Coad and Yourdon
This method is introduced (see [ 6-2] and [ 6-3 ]) by Peter Coad and Ed Yourdon. Ed Yourdon is well-known in the world of structured software. The method claims to be suitable for technical and business information-systems, but emphasises data over process and state modelling.
OOA/OOO knows two phases: • Analyse-phase In the analyse-phase the specification of the system is modelied in five layers: • subject model subjects are mechanisms for controlling which portions of a model are considered or viewed by the developer at any given time. • classes & objects model classes and objects are abstractions of data and exclusive processing on the data • structure model structures allow the problem domain to be classified by complexity and inheritance to show how classes and object are organised and assembied • attributes and relations between objects Attributes or data elements ( instance variables) are the characteristic of objects that are acted upon by the object itself • services and message connections services are the operations performed by objects The 5 models must be developed in a spiral or incremental working method. • Design-phase In the design-phase the OOA-models are supplemented with additional implementation details, when moving in 000. Ouring design the layers are extended, using four major components: human interaction, problem domain, task management and data management.
Project-structure and project-execution are not supported. The analyse and design phases are very weil connected, which makes the method suitable for an iterative strategy. OOA/OOO does not provide object-management or services to promote object-reusability.
Coad and Yourdon claim the biggest advantages of OOA/OOO are the smooth bridging between the analyse- and design-phase, the uniform presentation in analyse- and design-phase and the spiral-strategy and incremental way of development.
In article [ 6-19 ] is mentioned that OOA/OOO is inadequate for serious application because the underlying model only slightly extends what information modelling has offered for more than a decade. Further the method lacks a clear set of steps for building the modeis, for transforming . analysis deliverables to design deliverables and for resolving physical design issues.
Article [ 6-4] contains the result of experiences by NMB-Postbank Groep. A strong point of the method is data-modelling. As weak points are mentioned that developers have difficulties in understanding the OO-models, the method described is not detailed enough for large applications and the method does not force to an object-oriented way of thinking.
The following set of CASE-tools are supporting the OOA/OOO-method • ObjectPIus by Easyspec Inc • ObjectMaker by Mark V Systems Ltd. • Object-Oriented Environment by Fuji Xerox Information Systems.
page 57 J.H.M. Lemmers Structured development of real-time software Chapter6
6.8.8 Other methods
There are more then forty object-oriented development methods available, to much to mention all, but I want to point out the following: . • Hat/eyand Pirbhai A method very similar to SAISO of Ward and Meiler. • Unified Method The Unified Method is a new method, which is momentary developed by Booch and Rumbaugh. The developers claim that the Unified Method combines the best of OMT and the Booch method. The Unified Method will be introduced in spring 1996. • Object-Oriented Design (000) by Martin and Odell The fundament ot this method is formed by logic and sets. There is no separation between dynamic and statie behaviour. The statie aspects are derived from the dynamic behaviour. • Hierarchica/ Object-Oriented Design (HOOD) HOOO is specifically developed to support the design of software to be written in Ada and has been developed by the European Space Agency (ESA). The HOOO strategy is globally top-down and consist in a set of basic design steps, in which a given object (called parent) is decomposed in smaller components (child objects) which together provide the entire functionality of the parent object.
page 58 J.H.M. Lemmers Structured development of real-tlme software Chapter 6
6.9 Evaluation
If you take a global look at the methods, they show much common aspects. Almost every method has specification, design, implementation sequences. Besides almost every method makes a distinction between statie, dynamic and functional behaviour .
Much of the not-real-time methods use traditional techniques, dataflow diagrams, state diagrams, scenarios. Further almost all methods use the analysis, concurrency and detail/implementation cycle. The last common factor is the separation between statie and dynamic behaviour. In the analyse phase the methods show much overlap, especially the methods OOA/OOO (CoadNourdon), OMT, 000 (Booch) and OOSA (ShlaerlMellor). In the design phase the overlap is much less.
The OMT methods shows much potential, It is supporting the life-cycle, uses good description techniques and a reasonable support for dynamic behaviour. The lack of attention for the system and subsystem architecture is a disadvantage, especially for large projects. OMT and Shlaer/Melior are strongly related. However Shlaer/Melior is better equipped for large projects and OMT supports better the OO-principles.
Also Booch is a weil known and weil supported methodology, in contrast to ROOM. ROOM is only supported by one CASE-tooi and there is less literature available.
ROOM and SOL are the only two methodologies without a specification-design sequence. These methodologies mix specification and design work.
SOL is widely used in the world of telecommunication. This results in the fact that SOL is weil documented and weil supported by CASE-tools. The mathematical basis of SOL provides this methodology a good basis for validation and verification.
Object oriented methodologies are very suitable for designing the interfaces of embedded and real-time systems, by increasing flexibility and decreasing errors.
In literature the opinion on the suitability of (not-real-time) object oriented methodologies de pends on the purpose of an artiele. Artieles including a test of the suitability of several methods for real-time applications, concluded all methodologies fail. They mention that some methodo logies pay extra attention to the dynamic behaviour of a system, but a large number of aspects of real-time applications are neglected. However some artieles including a report on the usage of a methodology are far more optimistic. They adjust a methodology to compensate the short comings.
Every methodology is capable of supporting parts of the dynamic behaviour of a real-time system, but no methodology is capable of satisfying a developer of real-time software completely..
Including time constraints to the specifications and the design of a system is only useful when the system is validated checking if these time constraints are met. If developers are not able to validate if a system wiJl meet the time constraints, the developers have to run the application on hardware which will be used when the system will be in operation and the time constraints are checked by measuring in real-time the system performance.
If a structured development methodology is used, the use of a CASE-tooi is also necessary. Without a CASE-tooi structured development is a difficult task. The CASE-tooi supports the import of specifications and design and it takes over the validation and verification tasks (see [ 6-18]).
page 59 J.H.M. Lemmers Structured development of reaI-time software Chapter6
6.10 References
Books: [ 6-1] Grady Booch Object-oriented Design; with Application ; second edition BenjaminJCummings, 1994, ISBN 0-8053-5340-2 [6-2] P. Coad & E. Yourdon Object-Oriented Analysis, second edition Prentice Hall, 1991 [ 6-3] P. Coad & E. Yourdon Object-Oriented Design Prentice Hall, 1991 [ 6-4] Nederlandse Gebruikersgroep van Gestructureerde Ontwikkelingsmethoden 13 Methoden voor object-georiënteerde systeemontwikkeling Een vergelijkend rapport van de NGGO Uitgeverij Tutein NoJthenius, 1994, ISBN 90-72194-35-7 [ 6-5 J Nederlandse Gebruikersgroep van Gestructureerde Ontwikkelingsmethoden 16 Methoden voor systeemontwikkeling; een vergelijkend rapport van de NGGO Tutein Nolthenius, 1990, ISBN 90-72194-17-9 [ 6-6 J J. Rumbaugh and others Object-Oriented Modeling and Design Prentice Hall, 1991, ISBN 0-13-629841-9 [6-7] Roberto Saracco, J.R.W. Smith, Rick Reed Telecommunications Systems Engineering using SDL Elsevier science publishers bv, 1989, ISBN 0-444-88084-4 [6-8] Sally Shlaer and Stephen J. Mellor Object Lifecycles, Modeling the World in States Prentice Hall, 1992, ISBN 0-13-629940-7 [ 6-9 ] Sally Shlaer and Stephen J. Mellor Object-Oriented Systems Analysis: Modeling the World in Data Yourdon Press,1998 [ 6-10] J.P. Vermeir Methodisch ontwerpen van programmatuur voor reaf-time besturingssystemen Afstudeerverslag TUE, vakgroep meet®el, 15 oktober 1990 [ 6-11 ] Hans van Vliet Software Engineering; principles and practice John Wiley&Sons, 1993, ISBN 0-47-93611-1 [6-12] Paul T. Ward and Stephen J. Mellor Structured Development for real-time systems volume 1 : Prentice-Halllnc., 1985, ISBN 0-13-854787-4 volume 2: Prentice-Halllnc., 1985, ISBN 0-13-854795-5 volume 3: Prentice-Halllnc., 1986, ISBN 0-13-854803-X
Articles: [6-13] Michael J. Chonoles and Clinton C. Gilliam Real-time object-oriented system design using the object modeJing technique (OMT) Journalof Object Oriented Programming (JOOP) June 1995, page 16. [6-14] B. Oasarathy Timing constrains of real-time systems : constructs for expressing them, methods of validating them IEEE Transactions on software engineering, no 1, 1985 [6-15] Mohamed E. Fayad, Wei-Tek Tsai, Richard L. Anthony and Mitlton L. Fulghum Object modeling Technique (OMT) : Experience report Journalof Object Oriented Programming (JOOP) 7, no 7, 1994, page 46
page 60 J.H.M. Lemmers Structured development of real-tlme software Chapter 6
[6-16] J.C. Kel1yand Y.S. Sherif Comparison of four design methods for real-time software development Information and Software Technology, Vol 34, no 2, february 1992, page 74 [6-17] G.P.M. van den Goor, S. Brinkkemper en S.Hong Objectgeoriënteerde ontwerpmethoden Informatie jaargang 35 nr 12 page 840 [6-18] P.H. Goossens Gestructureerde analyse- en ontwerpmethode toegepast op een robotbesturingssysteem afstudeerverslag, afstudeerwerk TUE, vakgroep ER, augustus 1991 [6-19] Chris Loosley, Alex Mimo, Dan Richards and Paul Winsberg A Survey of Object-Oriented Methods InfoDB Spring 1994, page 31 [ 6-20] Michael M. Lee and Leon L.J. Starr Object-oriented analysis in the real world Technology of Object-Oriented Languages and Systems Europe '93, page 127 [ 6-21 ] Libero Nigro A real-time architecture based on Shlaer-Mellor object lifecycles Journalof Object Oriented Programming, march-april 1995, page 20 [ 6-22] P. Occelli Object versus functional design Presented at an AGARD meeting on 'Aerospace Software Engineering for Advanced Systems Architectures, May 1993, page 6-1 [ 6-23] Heinz Schneeweiss Shlaer/Mellor or Rumbaugh ;A Discussion of two popular object-oriented methods Ada in Europe ; first international Eurospace-ada-europ sup. proc. page 155 [ 6·24] Bran Selic, Garth Gullekson, Jim McGee, lan Engelberg ROOM: An object-oriented methodology for developing real-time systems Bell-Northern Research Ltd. Ottawa Canada Presented at CASE'92 fifth international workshop on Computer-Aided Software Engineering, Quebec, Canada July 6-10,1992 [ 6-25] Desmond D'Souza Dynamic modeling of object-oriented systems Conference proceedings aap '93/C++ world, 1993, page 113 [ 6-26] S.C. Stobart, A.J. van Reeken, G.C. Low, J.J.M. Trienekens, J.O. Jenkins, J.B. Thompson & D.R. Jeffery An Empirical evaluation of the use of CASE tools Proceedings 6th international workshop on Computer Aided Software Engineering CASE '93, page 81 [ 6-27] Andrew Topper Comparing Object-Oriented Methods Proceedings of the 5th annual embedded systems conference, 1993, vol 2, page 375 [ 6-28] David T. Wright and David J. Williams Object-Iike software design methods for intelligent real-time process control Transactions of the institute of measurement and control, 1994, vol 16, iss 1, page 48
page 61 J.H.M. Lemmers Structured development of real-time software Chapter6
page 62 J.H.M. Lemmers A survey of CASE·tools Chapter7
7. A survey of CASE-tools
7.1 Introduction
The definition of CASE is Computer Aided Software Engineering. A CASE-tooi is a tooi for the development of software, using a computer. There are people who believe the definition should be Computer Aided Systems Engineering, because the word systems implies a broader meaning than software.
In paragraph 7.2 the term CASE-tooi is explained. Furthermore code generation ( paragraph 7.3) and the selection of a CASE-tooi (paragraph 7A) is discussed. The most important paragraph of this chapter is 7.5, contains a survey of CASE-tools.
7.2 A CASE-tooi
A CASE-tooi supports a software developer by providing facilities, needed by system development methods. A tooi provides an (graphical) environment to make it possible to visualise and to record the produced system specifications and system architecture. But a CASE-tooi is more then a drawing tooI. It is extended with facilities to guarantee that the system-architecture satisfies the design rules, to run simulations, to generate code, produce documentation and control the different versions. A CASE-tooi always supports one or more development methodologies, describing how the specifications and the design will be recorded.
The case-tools that support the analysis- and design-phases of a systems development methodology are commonly termed as front-end or upper-GASE-tools. Those software produets that support the construction and implementation parts of the methodology are usually known as back-endor /ower-GASE-tools.
The primary reasons for the adopting of CASE should be build around the need for : • improving software and system quality that are developed • reduced development and maintenance cost • increased productivity • faster delivery • improving quality of documentation • improving manageability • improving communication between project-members and future users.
Using a CASE-tooi is not a guarantee to obtain these goals. There are a lot of pitfalls to be avoided: • Increased productivity is lost due to problems of applying the tooI. For example the tooi uses large amounts of processing time to re-compile the code between each design amendment • Large amounts of money have to be invested in training, tools and getting started. • No guarantee for improving results • 'Oft the selt' packages are not satisfactory • Tools do not ofter the possibility to use several methods in an integrated manner • Sometimes the methods, used by an organisation, have to be changed. This is not easily done. • Laek of project-management faeilities • The coupling of design data to the tooi repository is week • multi-user facilities are not satisf~ctory These pitfalls require a very careful selection process.
page 63 J.H.M. Lemmers A survey of CASE-tools Chapter7
7.3 Code-generation
Automatic code generation means automatic translation of a representation of an architecture, using a structured methodology, into a high-Ievellanguages. Reasons for automatic code generation are improving quality by decreasing code-errors and increasing production. When talking about automatic code generation, there are two important objectives to meet: • Code must meet project constraints. It is not enough to generate automatically, the code must be useful to the project • Code that is produced must work without modification Changing the generated output defeats the purpose of automatic code generation. Modifying the generated output is anaJogous to tweaking the object code after it is generated by the compiler.
Toois, able to generate code, can be c1assified into one of the following three levels of code generation ability: • headers only For each class, a .h plus .cpp files ( for the CH language) and other declaration information, but without any executable code. To complete the implementation, the user must add the code for member function bodies. Tools vary in the method by which a user could add these member function bodies. At the most basic level, a user finishes the model, generates the headers, and then starts adding code to implement the member function bodies into the generated file. If a later change in the model requires the user to regenerate the headers all the user-added code is lost and must be added again. A5 an improvement on this approach, same tools preserve user-added code when regenerating headers. This is typically done by inserting special comments into the header file to discern tool-generated code from user-added code. Finally, same tools allowed the user to add code directly to the model. The tools then merge the user provided code into the generated headers to produce a ready-to-compile impiementation. • headers and tinite state machines CASE-tools in this level generate header files and code from state transition diagrams. With these tooIs, the user tiJ/ed in the code which would be executed on transitions, and the taal combined this with a finite state machine walker to give a full finite state machine implementation. • tuil code generation CASE-tools, which are able to full code generation, have to include the static, functional and dynamic properties of a system. Examples of important aspects are the generation of: * a class for each object defined * events defined for all object communication * state transitions * finite state machines * embedded testing capabilities such as event tracing and class member dumping.
Using automatic code generation can result in restrictions on the allowed design structures. Furthermore it may be possible that complex functionality, algorithms and code requesting maximum performance have to be implemented by hand.
page 64 lH.M. Lemmers A survey of CASE-tools Chapter7
7.4 The selection of a CASE-taal
The selection of a CASE-tooi is a difficult task and failure can cause negative consequences. It results in loss of time and money and can create a negative image of a resource with potential power in an organisation.
The selection process must ensure that, at each successive stage of the methodology, the CASE-tooi will be appropriate for the system development process. When the CASE software evaluation and selection is started, the system development method, which will be used, must be known.
The evaluation is started with a screening of prospective candidates and development of a short list of CASE software packages. The screening criteria for CASE Tools will contain relatively few items and should concentrate on tunctional requirements not commonly provided and which are very specitic to the systems development methods. The CASE tooi screening criteria can be categorised into four major types: • technical requirements A CASE-tooi must be compatible with the selected hardware and system software, programming languages, peripherals, data communication capabilities. • tunctional requirements Functional screening criteria represent software capabilities that the CASE software tooi must absolutely offer for the systems developer : * support tor the phases ot the system development life-cycle * support tor all phases in the development process, including analysis, design, implementation (code-generation), testing (debugging) and documentation * the supported software-development techniques and the integration between these techniques * version control * hardware and software portability * integrated features * full repository * network support * the quality ot the human-interface • documentation and training * the availability of vendor developed training sessions and materials may be very important. * high quality documentation to install and support the software. * short learning periods • vendor information Important considerations are: * the expected growth potentialof a tooi • the vendor ability to support the CASE tooi through training, consultation, installation and maintenance assistance • the continuity of the vendor and the services supplied by the vendor • reputation of the tooi and the vendor • the unit price
The evaluation must be focused on a smalllist of suitable CASE tools, so that a better draught can be achieved. The evaluation results in a selecting of one or more CASE tools, which best suits the systems development requirements.
page 65 J.H.M. Lemmers A survey of CASE-tools Chapter7
7.5 Survey of case-toaIs
This paragraph contains a survey of CASE·tools. The criteria for the selection of the CASE tools mentioned in this survey are: • tuil life-cycle support • special design tor real-time applications • tor code generation the language C++ is preferred • available tor a windows platform • level of popularity, tor example how many time a CASE-tools is mentioned in newsgroups and in the literature.
In the following paragraphs interesting CASE-tools, which attract attention, are explained in more detail. In addition to this appendix 0 contains a summary ot CASE-taal specitications. This appendix also contains CASE-tools not specialised in development of real-time applications. .
page 66 J.H.M. Lemmers A survey of CASE-tools Chapter7
7.5.1 ObjectGEODE and LOV OMT by Verilog
Verilog offers three products, supporting development of real-time and embedded software. These three products are: • Logiscope • ObjectGEODE • LOV/OMT
ObjectGEODE is a CASE solution for the specification, design, verification, validation, code generation and debugging of distributed and real-time applications. ObjectGEODE is suitable to develop communications and real-time systems. MSC is used to record requirements and scenarios. The functional specifications of the systems are described in SDL.
ObjectGEODE is capable of managing large projects thanks to multi-user capabilities that can be linked to a 'version and configuration management system'.
The ObjectGEODE C application builder can provide 100% executable code of a multi-task and distributed application from an SDL description. Makefiles are also generated to automate the building process. The generated code is readable and open i.e.: it can be modified safely (without loosing tractability and reproducibility) and connected with external code. A application, generated by ObjectGEODE, requires an underlying Real-Time Executive (RTE) system in order to run. The generated code is independent of the individual target system and can be easily mapped onto other RTEs.
ObjectGEODE also provides the means to graphically debug, at SDL level, an application in its actual execution environment.
LOV/OMTcomprises of a suite of tools that support the OMT methodology for fuillife cycle development of object oriented applications. C++ and SOL code generation is built in with strong customisation features allowing for weil documented and optimised source code.
The LOV/OMT product is proposed in complement to ObjectGEODE. LOW/OMT respects the OMT notation and provides a coupling module with ObjectGEODE, the LOV/OMT SDL generator, 50 that these tools could be used in a combined way on real-sized projects.
Logiscope is a tooi to evaluate developed software before putting it into service. This evaluation with respect to the objectives defined at the start of project allow the software's characteristics to be predicted. Logiscope provides the developer a feedback mechanism.
In all phases of the life cycle the quality requirements, expressed and defined in the earlier phases, must be verified. Test strategies are defined during the first phases of the software construction. Logiscope ensures that a satisfactory level of testing has been obtained. Logiscope is capable to validate the quality of the architecture and of the coding.
page 67 J.H.M. Lemmers A survey of CASE-toots Chapter7
7.5.2 ObjecTime by ObjecTime lirn.
ObjecTime is developed by ObjecTime tim. and is a development environment for real-time software.
ObjecTime offers graphical models based on the ROOM methodology Such modeIs are compiled and executed on a simulator that allows the developer to validate the model. The simulator provides visualisation capabilities including animation of state machines and message flows.
ObjecTime provides facilities for capturing requirements ( textually or as message sequence charts). Ouring the design states are executable models used for validation, if these requirements are met.
Although primarily graphical, some aspects of the model require traditional programming. To address this, ObjecTime is integrated with C++ language environments. The resultant model runs on an emulation of the target run-time environment.
The ObjecTime tooiset is available on SUN, HP and IMB RS/6000 workstations. Complete high-performance product-quality code generation is available for workstations operating system and leading real-time operating systems including VRTx, pSOS+, VxWorks and QNX.
7.5.3 SDT by Telelogic
SOT is a design tooi developed by Telelogic. SOT supports SOL and MSC. SOT offers facilities to record requirements and specification and facilities to design, to verify, to validate, to simulate, to implement and for testing. Multi-user projects are supported.
SOT includes editors to record MSC-diagrams for requirements and SOL-diagrams for specifications and design. The analyser verifies the system created by de SDL editor. The SOL diagrams are checked for syntax and semantic errors.
After the verification the system can be simulated and validated. The simulation facility in SDT is provided by the C Code Generator together with the Simulator and the performance Simulator. The validator supports automatic exhaustive validation of SOL specifications as weil as any C code included. The validator will find dead-Iock conditions, data operations errors, etc. It also offers the feature of automatic consistency verification between user defined MSC and SOL systems.
In the implementation phase the final executable system is created. SOT supports the automatic translation from SOL to C, C++ or CHILL environments. Existing C and C++ code can be included in the SOL application. The application can use the services of an operating system (for example pSOS+, VRTx and VxWorks) or an executive, but can also be executed on a bare machine using the SDT run-time mechanisms.
A software product related to SDT is ITEX, a test suite management platform. It is a tooi that helps the user develop test suites for conformance testing of an implementation.
page 68 J.H.M. Lemmers A survey of CASE-toals Chapter 7
7.5.4 ObjectTeam by Cadre Technologies Inc.
Cadre supplies a set of CASE-tools, including ObjectTeam for OMT and ObjectTeam for Shlaer/Mellor.
ObjectTeam OMT provides a common online repository, that enables multiple users to always have access to the same project information. Project-data is accessible for all developers, but a locking system prevents objects in the repository from being modified by two users at the same time. Developers can create more than one version of projects, configurations and diagrams.
ObjectTeam OMT provides a extension on OMT by allowing classes to be grouped into subsystems. Code reuse is promoted by providing a class analysis and browsing facility to the repository and enforcing styling and naming conventions.
Further ObjectTeam has document templates that follow the structure of the OMT method and provides the flexibility for users to create their own documents.
ObjectTeam for OMT provides complete implementation support. Users can compiIe, test and run applications as weil as generate makefiles and reference external class libraries. Object Team OMT supports C++, ADA, SmallTalk, and SOL code generator. When an user edits a diagram and regenerates the code, the code introduced by an editor is not lost. Users can optimise the code generators to support specific features of a compiler, such as C++ templates or different implementations for the associations, through their own container classes.
ObjectTeam for OMT's SmallTalk and C++ reverse engineering modules read source code and then translate this code into an object model according to OMT conventions.
The ObjectTeam for Shlaer-Mellor provides all facilities, which are provided by ObjectTeam for OMT. But Cadre also supplies ObjectTeam/Sim, an OOA simulation tooi, providing an organised way to create, change, execute and monitor simulations. Developers can design and execute test scenarios and then view the test results on the screen.
page 69 J.H.M. Lemmers A survey of CASE-tools Chapter7
7.6 Evaluation
The adoption of CASE technology not only introduces technological change, but more importantly introduces a change in the basic philosophy of systems development. In some instanees the organisation will experience a 'culture shock' when embarking upon the implementation of the CASE environment.
Ouality improvements is not achieved by only introduction of the proper methods and tools. Ouality is a very complex phenomenon that is influenced by many factors, technical, organi sational as weil as psychological. Improvement of systems quality can be achieved only by addressing all of these. Furthermore one should not assume that CASE-tools are designing for you. A CASE-tooi is and stays a tooi for developers.
CASE-tooi developers are not restricted by shorteomings of used methodology. They simple extend the supported methodology with facilities to compensate the shortcomings. This is an important point to consider, when a development methodology is selected.
CASE-tools, special support for object-oriented methodologies, automatic code generation, simulation, verification and validation are relative new technologies. This and next years the present tools will be adjusted and extended.
The most important reasons for using a CASE-tooi are: • When a structured development methodology is used, ~ is almost inevitable to use a CASE tooi to fully exploit the advantages • Increasing quality of the documentation and the syste,m developed • Reuse of software, the biggest advantage of all.
For the measurement and control group I want to recommend ObjectTeam OMT. The advantages of ObjectTeam OMT are: • support of the OMT methodology, extended with facilities to define sub-systems and facilities to improve support for real-time software development • support of Windows NT and Windows 95 environment ' • supported by a Dutch supplier, namely Koning&Hartman • Koning&Hartman claim ful! code generation, including support for VxWorks • Koning&Hartman has experiences using ObjectTeam for developing real-time software, in combination of VxWorks real-time operating system • In the future simulation maybe added to ObjectTeam OMT • Reasonable prize.
page 70 .H.M. Lemmers A survey of CASE-toals Chapter7
7.7 References
Articles: [ 7-1 ] Louis A. Le Blanc, Willard M. Kom A structured approach to the evaluation and selection of CASE tools Proceedings of the 1992 ACM/SIGAPP symposium on applied computing, 1992, 2 vol, page 1064 [ 7-2 ] Terry Church and Philip Matthews An evaluation of object-oriented CASE tools : The Newbridge Experience Proceedings of the 7th international workshop on Computer Aided Software Engineering CASE '93, page 4 [7-3] Rob J. Kusters and Gerard M. Wijers On the practical use of CASE-tools results of a survey Proceedings of the 6th international workshop on Computer Aided Software Engineering CASE '93, page 2 [ 7-4 ] Bil! Prather and Andersen Consuiting Critical failure points of CASE tooi evaluation and selection Proceedings of the 6th international workshop on Computer Aided Software Engineering CASE '93, page 60
page 71 J.H.M. Lemmers A survey of CASE-tools Chapter7
page 72 J.H.M. Lemmers The suitabllity of Windows NT for measurement and control purposes Chapter8
8. The suitability of Windows NT for measurement and control purposes
8.1 Introduction
This chapter is the starting point of the second part of this master thesis. This second part has a strong practical nature. This chapter describes the purpose and the construction of a test setup, used to examine the real-time performance of Windows NT and used to develop a measure ment and control application, using Windows NT as operating system (The MeCon-application, see chapter 9).
8.2 Purpose of the measurement
The purpose of this task is to create a facility to test and evaluate the suitability of Windows NT for running measurement and control applications. The test setup is used to determine th is suitability by measuring the real-time" and other characteristics of Windows NT. The real-time characteristics measured are also used to determine the specification of the measurement and control application (see chapter 9).
In order to establish the real-time behaviour of Windows NT, the following points are examined: • the response latency • the interrupt latency • the duration of the interrupt service routine • the maximum sample frequency • the influence of different kinds of loads on the real-time performance. During this research, not only attention is paid on the duration, but also the variations in the duration are very important.
The test setup is build using of standard and relative cheap PC-equipment. The equipment used is already available and familiar to the members of the measurement and control group. The setup is a low-cost system, providing the opportunity to the members of the measurement and control group to run and evaluate easily developed controllers.
The environment can be separated in a hardware part and a software part. • The computer equipment consists of a PC-computer containing a Pentium 133Mhz processor, 32Mbyte Ram and an E-IDE-harddisk. It is a standard, 'Iow cost' computer. A normal computer is used, because the aim is to create a setup with low cost. The computer is extended with a data acquisition board, the Keithley Data Acquisition DAS-1802HC. This board was already in possession of the measurement and control group. • The operating system is Windows NT 3.51.
As said earlier, the measurement and control group has chosen to use Windows software. And if you look at the specifications of Windows NT, it seems suitable for control-applications. Windows NT is an operating system, with good specifications. It has been designed from the ground up to be a highly responsive, general-purpose operating system. It is highly preemptive and it has a clear and consistent design and a 50lid scheduling algorithm, with facilities which are very interesting tor reaI-time purposes. .
Page 73 Chapter 8 The sultability of Windows NT for measurement and control purposes J.H.M. Lemmers
Furtherrnore the measurement and control group is planning to use Windows NT as server, making it unnecessary to introduce a new piece of software. Another édvantage is possibility to use measurement and control applications in combination with other software packets, like Matlab, spreadsheets and word proCESSors. A disadvantage of Windows NT is the need for a powerful processor and much memory, but the price for this hardware is strongly decreasing.
All together, it is very interesting to research the real-time behaviour of Windows NT and to examine if Windows NT is suitable for control purposes.
Page 74 lH.M. Lemmers The sultability of Windows NT for measurement and control purposes Chapter8
8.3 The measurement methods
The following time periods are measured (see figure 8-3 and figure 8-4 for the definition): • the response latency (Tpa) • the interrupt latency (Tps) • the duration of the first part of the interrupt service routine, which has influence on the response latency (Tso) • the maximum sample frequency • the time it takes to retrieve sample values and to do calculations, to establish T ad and Tra.
The response latency is measured by determining the time delay between a generated pulse signal offered to the PC and the generated pulse signal generated by this PC in response to the offered signa!. The generated pulse signal is offered to the ADDA-board, which is placed in the PC. The hardware board generates an interrupt, sa that the (SR (Interrupt Service Routine) in de AdDa-device driver is called. At this point there are two possibilities: • the direct method The response signal is generated at once in the ISR in the AdDa device driver (see figure 8-2). • the indirect method The ISR call results in a signal to the user application, which is responsible for generating the response signal, by calling a AdDa device driver to pass the new output value (see figure 8-1).
figure 8-1 Framework of the application, using the indirect method
•--ë-o-nijiUter-s).Sie-ni ------.---_. ------• ....------,
flgure 8-2 Framework of the application, using the indirect method
The advantage of the indirect method is that the algorithm is placed in an user application, which is easy to debug and much less sensitive for errors. Furthermore the device driver kit does not support f10ating point variables. But a major disadvantage is the increase of overhead. The system has to pass information from device driver to user application and back, which takes lot of time and an increasing number of context switches. The result is an increasing response latency.
Page 75 Chapter 8 The suitability ot Windows NT tor measurement and control purposes J.H.M. Lemmers
Furthermore the context switches and the requirement to run time-critical code at a lower priority level, lead to an increasing variation in the response latency. So the direct methad is the best method to use for the measurement and control application and 50 this method is used to measure the real-time performance.
The following are the definitions of the used points in time and periods of time (see figure 8 3a): •Tps : the minimum interrupt latency, the time the system needs to start the ISR after an interrupt is generated • öTps : the maximum additional T ps
•Tii : the minimum time which is needed to identify the interrupt
• öTü : the maximum additional interrupt latency, on top of T ii •Tad : the minimum time it takes to retrieve the sample from the data acquisition board • öTad : the maximum additional T ad • Tra : the minimum time it takes to run the algorithm • öTra : the maximum additional T ra •Tda : the minimum time it takes to retrieve the sample from the data acquisition board • öTda : the maximum additional T • t5 (n) : the point in time where the interrupt service routine is started • tad(n) : the point in time where analogue inputs are retrieved • ton) : the point in time where the new analogue output value is written to the AdDa-board • te(n) : the point in time where the new analogue output values is valid at output of the AdDa-board Tij I Tps identify Tad run pass data interru pt L...I----;------! interrupt read algorithm n send latency samples n output values n figure 8-3a procedure of a sample cycle tp(n) to(n) .~ . startmg pomt new output+ values of the sample cycle are sent to interrupt occurs the loard tJ.n) ! ~ lil I Tdac I interrupt I Tcrd I DA conversion latency latency by interrupt service routine the 110 card lii identify interrupt send output value figure 8-3b actions to generate a response to measure the response latency figure 8-3 Input response procedure, using the direct method Page 76 I.H.M. Lemmers The suitability of Windows NT tor measurement and control purposes Chapter8 The sample cycle consist of 3 phases, the retrieval of the samples, the execution of the algorithm and the sending of the new output values. Furthermore a phase is added to identity the interrupt. When the response Jatency is measured, the retrieval of the samples and the running of the algorithm is not performed, 50 T00=0 and Tra=O, and further the number of outputs is minimised to one output. This result in a new procedure, visualised in figure 8-3b. Like mentioned earlier, T pa (the response latency) and Tso are measured by offering a block signal to a digital input of the AdDa-board. When the board detects an edge, an interrupt is generated and the interrupt service routine (ISR) of the AdDa device driver is called. 'The ISR cancels the interrupt and writes a new output value to the AdDa-board, resulting in a new analogue output value at the analogue output of the board. to~n+1) tp'(n-1) to(n-1) tp(n) tp(n+1) n 1 t~(n) : t (n+1) i t (n+1) 1V- ) t8(n-1) : s e : :,'1: (n-1 1: (n): : : 1: (n+1) 1.• j, po i ~ ss :' : - " ps",--••"':.•o---""';"-""""'-""-'------+:_ : ~1: (n-1): : ~,Lso(n>:, : 1: (n+1): : •: pe :. ' ::_.-=-=----<....----,:~O.lo!.o _----;.-:--'-- .' -1" I' period n~1 period n period n+1 figure 8-4 Definition of the time periods measured Both the input and the output signal are visualised at an oscilloscope. The response latency (Tpe) is the time delay between the edges of the input-signal and the output-signal. These response latency is determined by a DSP, measuring the length of the time period between the edges. The influence of concurrent tasks and activities on the real-time performance is researched through loading the PC with extra tasks. Three measurements are carried out: • a measurement with minimum load In this situation the device driver responds to an interrupt and passes every interrupt information to the user process. • a measurement with data logging as load This is the normal situation. The system has to deal with, when it is performing acontrol task. The device driver passes, after running the control algorithm, every interrupt infor mation to the user application, which logs the data to disk. • a measur.ement with maximum load This measurement is carried out with writing to disk, moving the mouse, a clock on the screen and keyboard activities. A thread, with a low priority uses all remaining free computer capacity, to open a file, write some data to this file and delete this file. Another interesting point to investigate is the maximum sample rate. The maximum sample rate and the processor load are determined for the sample rates of 170Hz and 3KHz and for the three above mentioned types of load. To determine the maximum sample rates, the performance monitor is used. The performance monitor is a tooi of Windows NT, which visualise graphical all kinds of performance-figures, The measurements will be carried out by two frequencies: • 170Hz This is a low frequency at which the computer is not heavy loaded and is a frequency which is quite realistic compared to frequencies that appear in control applications. • 3KHz At this frequency the load of the system is quite high. It is interesting to see if the system acts different, compared to the 170Hz. A frequency of 170Hz means, that every second 170 interrupts occur. If these interrupt are used to generate a block-signal, this signal will have a frequency of 85Hz. Page 77 Chapter 8 The suitabillty of Windows NT for measurement and control purposes J.H.M. Lemmers Tii , Tad and Tra are measured using the same technique. These operations are removed from or placed into the time-critical part of the ISR, after which the durations are determined, by measuring, with the oscilloscope, the changes in the response latency. The periods are: •Tad is measured by introducing the retrieval of 4 sample values. The start of the retrieval of the samples was started up by the software. This is the slowest method. The AdDa-board is able to start automatically the A-D conversion at the clock-interrupt. So it is possible to decrease the Tad conversion time. •T jj is measured by moving the identification of the interrupt to the end of the ISR, where the new output value is already written to the AdDa-board • Tra is determined by measuring the duration of 1000 calculations with longs (32bits integers) is measured by putting such calculation in the ISR. The code consists of a loop and every loop four calculations are executed. ~t is not possible to measure Tda. This figures are based on the specifications of the manufac turer of the board. Page 78 J.H.M. Lemmers The suitability ot Windows NT tor measurement and control purposes Chapter 8 8.4 The test setup The source signal to the PC is a block signal, offered to a digital input of the AdDa-board. On él' negSltive edge, the board starts the cascade counter1!counter2-combination. These counters, with a clock of f=5Mhz, are both loaded with the minimum value 1, so that the board generates an interrupt after OAJls. The ISR is optimised for every measurement. This interrupt starts the Interrupt Service Routine (ISR) of the AdDa device driver. This ISR performs the following actions: 1. determine ts (is only performed when a Tso measurement is carried out) or the counter- values of the AdDa-board are determined (in case of the Tps measurement) 2. cancel the interrupt 3. write the new analogue value to the AdDa-board 4. determine to (is only performed when a Tso measurement is carried out) 5. if a read-request is pending, the measurement data is stored in the read-buffer and the read request is completed The input and the output signals are visualised on an oscilloscope. The scope is triggered by the input-signa!. The response latency (Tpa) is determined by measuring the time-delay between the input-signal and the output-signa!. But if an oscilloscope is used to measure the response /atency, then only the average latencies are visible. But the maximum latency is much more interesting, because the maximum value establishes the minimum guaranteed response time. To analyse exactly the response latency, a DSP is used. This DSP measures every response latency. The response latencies measured, are divided in groups of 1Jls and the number of occurrence of these latencies are counted for every group. The DSP-hardware scans the two analogue signals every 25ns for an edge. If an edge is detected the timestamp of this edge is stored. Every 100Jls a routine is executed by the DSP. It scans if the hardware has detected an edge at the PC-output signa!. In such occasion the DSP calculates the response latency by determining the period of time between the edge ofthe PC output-signal and the last edge of the PC input-signal To measure Tso, instructions are added to determine the exact points of time of t o, tso The timestamp to and ts are determined by reading the system-clock, placed on the mother-board. Is is the timestamp, right before the first instruction of the (SR is executed. t ois the timestamp right after the new analogue output values are written to the AdDa-board. The frequency of this system-c1ock is 1.19MHz, so the resolution is 0.84j.J.s. When these counter values at points of time ts and te are known, it is easy to determine Tso by calcuJating the time between the points of measurement. These calculated values are divided in groups with a specific value and for every group the number of occurrences are counted. Tps is measured, not by using the input signal, but by using the counter1!counter2 combination of the AdDa-board as trigger to start the response. Both counters count back to one, with as source a clock (f=5MHz) placed on the AdDa-board. When the one values are reached, an interrupt in generated and the counters automatically reload themselves with the reset-value. When the ISR is started, first the counter values of counter1 and counter2 are read, so the ISR is able to determine how much time has elapsed, after the generation of the interrupt. These calculated values are divided in groups with a specific value and for every group the number of occurrence are counted. The used equipment are: • the Philips PM5131 function generator • the Philips PM3350 digital oscilloscope • the Fluke 8000A digital multi-meter • the Fluke 7260A univeral counter/timer • dSpace DS1003 DSP. Page 79 Chapter 8 The sultability of Windows NT for measurement and control purposes J.H.M. Lemmers 8.5 The measurement expectation Figure 8-3b shows the actions, which musttake place to realise a response: The response latency can be estimated by determine the duration of each action. After an edge of the input signal, tabie 8-1 Measured response latency ( see appendix E) the AdDa board counts twice befare Measurement an interrupt is generated. Two clock Duration [Jls] ticks takes: minimum maximum hardware interruDllatencv 1 1.8 2.9 interrupt dispatchino 4.6 10.5 T =2 * 5*106 =0.4J,1S interrupt service routine lenoth 10.3 16.7 lotal elapsed time 16.7 30.1 Ta estimate the interrupt latency, Computer: Pentlum 90MHz, 16Mbyte we take the results of a survey, which are placed in table 8-1. For a Pentium 90MHz the measured interrupt latency was between 6.4j.ls and 13.4j.ls. Our system has one Pentium 133MHz, so the measured interrupt latency wil! probably be less. The relevant part of the ISR, consists of one read operation from and four write operations to the AdDa-board. Because this are complex operations, I'm not able to estimate the duration of these actions The manufacturer claims the boards needs typical 61ls and maximum 30llS to reach a new output value at the analogue output. These specifications are based on a step from -10V to 10V. Because I'm not able to estimate exactly the duration then all the parts, I'm not abIe to estimate the response latency. But on basis of the measurement in table 8-1, the response latency should be between 1&.ts and 3~s. There are only two devices with a higher interrupt level of the AdDa-device driver (level 11). These devices are the IDE-disk device (level 14) and the clock (leveI16) (see appendix E, table E-1 and table E-2). 50 four possible scenarios are imaginable: 1. No timer or disk interrupts occur during the handling of an interrupt of the AdDa-device. This case has the highest chance to occur and so this wil! result in a peak in the number of counts of a particular measurement value, inside a particular range. 2. Only a timer interrupt occurs during the handling of an interrupt of the AdDa-device. This case will result in another peak at a higher latency value. The number of occurrences must correspond to frequency of the clock interrupts. 3. Only a disk interrupt occurs during the handling of an interrupt of the AdDa-device. Also this case will result in a peak at a higher value. The shape and the width of this peak depends on the length and variation in the length of the activities of the disk device driver ISR. 4. Bath a clock and a disk interrupt occur during the handling of an interrupt of the AdDa- device . At the handling of these interrupts the largest response latencies occur. Because the time it takes to handle a AdDa-device interrupt, it is not expectable that two or more clock-interrupts occur. The clock period is 15ms. Page 80 J.H.M. Lemmers The sultabillty of Windows NT for measurement and control purposes Chapter8 8.6 The measurement results Table 8-2 shows the results of the measurement of the response latency, Tps and Tsa and table 8-3 contains the measurement results, done to determine the maximum capacity of the system. Appendix H contains tables with the counted values and graphics of the measurement. Table 82- Measurement 0 f th e response atency Response Board Interrupt Tso DA- latency latency latency conversion measured Tcrd Tps Tdac [us] [~s] [~s] [~s] [~s] minimum 12.0 <1 10.0 9.8 6 na averaae 13.4 <1 11.1 10.6 6 load 99,9% 22.0 <1 21.0 18.8 6 99,99% 26.0 <1 27.0 22.5 6 minimum 10.0 <1 10.0 9.0 6 f=170Hz log averaae 16.5 <1 15.1 12.6 6 load 99,9% 29.0 <1 32.0 26.3 6 99,99% 34.0 <1 41.0 30.8 6 minimum 12.0 <1 10.0 8.3 6 heavy average 20.4 <1 15.8 12.4 6 laad 99,9% 45.0 <1 33.0 33.0 6 99,99% 56.0 <1 44.0 48.0 6 minimum 11.0 <1 7.0 8.3 6 na averaae 13.4 <1 9.7 9.9 6 load 99,9% 22.0 <1 18.0 11.3 6 f=3KHz 99,99% 27.0 <1 24.0 21.0 6 minimum 10.0 <1 7.0 7.5 6 heavy averaae 15.5 <1 10.0 9.6 6 laad 99,9% 28.0 <1 22.0 27.0 6 99,99% 34.0 <1 32.0 39.0 6 Table 8-3 Capacity of the system occupatlon processor only device logging to logging to disk driver memory buffer 170 samoles/sec <5% 5%-10% 65% 3000 samples/sec 5%-10% 70% >100%<: Maximum sample rates only device logging to logging to disk driver memory buffer maximum samole rate 40KHz 12KHz 205KHz Like said earlier, only devices with a higher interrupt level then the AdDa-board are able to delay the ISR. These devices are the system clock and the IDE-disk device. Therefore, when the system is loaded with no load at all, only the system clock will be visible in the measurement data. The response latency measurement shows that 99.9% of the response latencies is smaller then 44J..ls and 99.99% of the latencies are smaller then 56J..ls. 2 The capacity of the system was to smalI, resulting in lost of sample-data, which are no logged to the datastore. Page 81 Chapter 8 The suitablllty of Windows NT tor measurement and control purposes J.H.M. Lemmers If we take a look at the response latency, Tps and the T&0 measurements with f=170Hz and no load, two peaks are visible. The first peak contains the measurements, by which no clock disturbance occurred. Furthermore there is a second peak, 1Qls after the first peak, containing the measurement where a clock interrupt occurred. By calculating the total duration the system needed to handle all measured responses added with the half of the clock period dividing by the number of time interrupts occurred, it is possible to establish the average occurrence of an extra delay in the response. If system has no additionalload this period is equal to the clock period (Tc1ock ): • Response latency 50,000 measurements with average response latency of 13.~s and the second peak contains 81 measurements, 50 50,000 *(13.4 +45) *10-6 Tc/od: = 81 =l1.1ms •Tps 50,000 measurements with average response latency of 11.1J..ls and the second peak contains 69 measurements, so 50,000 *(11.1 + 45) *10-6 Tc/ock = 69 =113ms • Tso 50,000 measurements with average response latency of 1O.&1s and the second peak contains 53 measurements, 50 50,000 *(10.6 + 45) *10-6 Tc/ack = 53 =143ms These approximated clock periods are smaller then the real-time clock period of 15ms. Distur bances can be caused by the statistical character of this measurement in account. An other explanation is that there are other interrupts then the clock interrupts, but I don't know which device generates these interrupts. During the measurements it appeared that the fa and ts measurements where highly influenced by disk operation. With na disk load they introduced large delay of 25J..ls and this delay increased to 40J..ls when the system was loaded with heavy disk activities. Therefore the Tso measurements with log and heavy load are not very reliable. The values of Tso are large, compared to the response latencies. This is caused by the extra latency, caused by the read operation to establish the time elapsed. Now our focus is moved to the response latency, Tps and the Tso measurements with f=170Hz and a log and a heavy load. By these measurements not only clock interrupts occur, but also interrupts generated by the IDE-disk device. The response latency shows an additional delay, compared to situation with no load, of 4J..ls (log load and f=170Hz), 7J..ls (heavy laad and f=170KHz) and 31ls (heavy laad and f=3KHz). This delay was a surprise for me. I expected that additional peaks would appear, at higher values for the response latency, but that the first peak would stay at the same place, because this peak contains the measurements, which where not interrupted by other interrupts. So probably this delay is introduced by the interrupt manager, but another possibility is that the 110 operations are delayed by the disk activities. This phenomenon also appeared with the operation to establish the timestamps fa and ts, only this additional delay was much larger. The number of counts outside the first peak of the measurement of the response latency (f=170Hz and log laad) is increased from 81 to 133. This increase must be the interrupts generated by the disk device. The disk ISRs result in a wide peak, containing measurements with an extra delay between 2J..ls and the 20J..ls. There is also one count around the 5~s. This large delay is probably the result of 2 interrupts, but I have no exact explanation for these phenomena. Page 82 J.H.M. Lemmers The sultabllity of Windows NT for measurement and control purposes Chapter8 When a heavy load was introduced, the number of interrupted measurements increased trom 81 to 360 counts. These additional counts must be responses interrupted by one of more disk interrupts. Furthermore the measurement with the heavy load shows one large peak, again the measurements with one interrupt, and a band of counts between 1&ts to 44J.1.s. This band contains measurements where a clock- or a disk-interrupt occur. Furthermore there is a lower band trom 44J.1.s to 59J.1.s. This band contains the measurements with a log disk interrupt or with both a disk and a clock interrupt. The tength of the interrupts service routine of the disk device is strongly variabie. And of course there are the occasions where the disk's ISR is already partly handled, when the interrupt of the AdDa device occur. When the measurement with t=170Hz is compared tó the measurement f=3KHz, the measure ments shows no differences. This in contrast to the measurement with a heavy load. The variations in the measured values for f=3KHz are less then the variation tor t=170Hz. This is caused by the decrease ot the available processor time for the thread, which writes to disk. To measure Tra the duration of 1000 multiplications of longs (32-bits integers) are inserted in the ISR. The response latency increased with 76.&1s. Tad was measured for one sample and for four samples: • one sample :T ad = 160llS • tour samples :T ad = 650llS The time needed to identity the interrupt was measured by starting the ISR by generating the response signa!. This operation resulted in a decrease of the response latency by ~s. Page 83 Chapter 8 The suitability of Windows NT for measurement and control purposes J.H.M. Lemmers 8.7 Specifications After analysing the measurementdata, the next specifications are established: • The maximum sample rate is 2.5KHz if every sample is logged to disk. The sample rate can be increased to a maximum of 40KHz, by decreasing or stopping the logging. • The response latency is between 1Q..ts and 56~s. The variation is strongly dependable to disk activities. • The measured duration of Tii , T ad , Tra are placed in table 8-4. The variation of the duration of these operation (öTii , öTad and öTra) can be estimated by using the variation of the response latency as upper boundary. Tad was measured, using the slowest method to retrieve sample values by starting up the retrieval by the ISR. However the AdDa-board is abIe to automatically start the A-O conversion. •Tda is based on the specifications of the manufacturer of the board. It was not possible to establish every value after the measurement of the real-time performance, but some of the values can be estimated by a upper-band, for example the variation of the response latency. This upper-bound is allowed, because there are relations between the öT-values. For example because the ratio between the clock period and the length of the period it takes to generate a response, a clock interrupt can occur only one time en will only cause one high ÖTil , ÖTii, öTad, öTra or öTda-value. tabi e 84- SipeCITIcarlons W'Indows NT Minimum value Variation (99.99%) Maximum value [~s] [~sJ [~s] Response latency (T",,) 10.0 46.0 56.0 Average value [~s] Ti; 3 Tad for one channels 160 T~t1 for tour channels 650 Tr" (1000 calculations) 76.5 Tda 6 Page 84 J.H.M. Lemmers The suitability of Windows NT for measurement and control purposes Chapter8 8.8 Control algorithms and computational delay Since A-O and O-A conversions and computations take time, there will always be a delay when a controllaw is implemented using a computer. This delay, which is called the computationa/ de/ay, depends on how the control process is implemented. There are basically three ways to do this (see figure 8-5). In all these cases, it is necessary to take the computational delay into account when computing the controllaw. Paragraph 8.7 contains the conclusions and the specifications from the measurement. With these specifications and the above mentioned rules, it must be able to determine if Windows NT and the MeCon-applications are suitable for a particular measurement and control task. The possible orders for the digital controller calculations are (see figure 8-5): • Read-Algorithm-Send-order (RAS-procedure) • Send-Read-Algorithm-order (SRA-pracedure) • Read-Send-Algorithm-order (RSA-procedure) The following are the definitions of the used points in time and periods of time: • tp(n) : The point of time sample cycle n is started. • tad(n) : The ideal point of time the samples of sample cycle nare read. • t-ad(n): The real point of time the samples of sample cycle nare read. • tda(n) : The ideal point of time the output values of sample cycle n are in valid. • t-da(n): The real point of time the output values of sample cycle n are in valid. •Tps : The minimum and so the constant factor of the interrupt latency. • 8Tps : The maximum additional interrupt latency, on top of T ps. • T;; : The minimum time to identify the interrupt. • 8Tii : The maximum additional Tij •Tad : The minimum time it takes to retrieve the sample from the data acquisition board. • 8Tad : The maximum additional T ad. • Tra : The minimum time it takes to run the algorithm. • 8Tra : The maximum additional Tra. •Tda : The time it takes to send the new output values to the data acquisition board, including the time the board needs to the new values in force. • 8Tda : The maximum additional T da. •Tpe : The response latency. • 8Tpa : The maximum additional T pa. The RAS-procedure is·the intuitive procedure and is used to determine the response latency. A disadvantage of the RAS-order is that the delay will be variabIe depending upon the program ming. For the RAS-procedure applies the next rules: tud (n) =tp(n) + Tp.r + 1;; + Tud - tud(n) =tud(n) +ÖTps(n) +Ö1;;(n) + ÖTud(n) ~ tud(n) +ÖTp,,(n) tdu(n) = t/n)+ Tps + 1;; + Tud + Tra + Tda = tp(n) + Tp" - tdu(n) =tdu(n) +ÖTps(n) +ö1;;(n) +öTad (n) +ÖTra(n)+ ÖTdu(n) =ts,,(n) +ÖTp"(n). Tps Ti; and Tad are every sample the same and result every sample in a delay-time, 50 that these delays have no influence on the quality of the contral operation, but naturally they have influence on the maximum sample rate. Page 85 Chapter 8 The suitablllty of Windows NT for measurement and control purposes J.H.M. Lemmers The Send-Read-Algorithm-procedure (SRA-procedure) introduces an extra delay of one period before the new output values are sent out. This result in the advantage that the computational delay is (almost) equal to the length ot one period (if T sample» Tpa + öTpa). Disadvantage is that the control actions are delayed unnecessarily and variation is introduced in the point ot time the samples are read. For the SRA-procedure the followlng rules apply: tad(n) =t p(n) + Tps + 1';; + TdiJ + 1;.d - tad(n) = tad(n) + oTp,(n) + oT;;(n) + oTda (n) +oTad(n) ~ tad(n) + oTp~(n) t diJ (n) = t p(n + 1) + Tps + T;; + Tda = tp(n ) + T Tps, Tii and Tda are every sample the same and result every sample in a delay-time, so that these delays have no influence on the quality ot the control operation. The last procedure is a variation on the SRA-procedure. By the RSA-procedure the new samples are read first, betore the output values trom the last samples are sent out. According to [ 8-1 ] (page 367), this procedure can result in electrical cross-coupling. For the RSA procedure applies the next rules: taAn) =tp(n) + Tp., + T;; + 1;.d - tad (n) =tud (n) +o~),(n)+oT;;(n) + o1;.d(n) ~ tain) +oTp/n) t diJ (n) = t r< n) + Tps + T;; + J:s + Tda - tdu (n) = t du (n) + oTp.,(n) + oT;i(n) +oT,s(n) +oTdu (n) ~ tdiJ (n) + oTp~(n) . Tps • Tij and Tad are every sample the same and result every sample in a delay-time, so that these delays have no intluence on the quality of the control operation. RAS-order start sample start cycle n routine ~ ~ tp'(n) ts(n) t t lij 1 identify Tad run pass data interrupt I'---..,.-----' interrupt read algorithm n send latency samples n output values n SRA-order start sample start cycle n routine ~ t (n) t (n) tp'(n) t:(n) o~ e~ t t III lii I identify I Tda raad pass data interrupt send samples n interrupt run latency output values n a1gorithm n RSA-order start sample start cycle n routine ~ tadn) tda Page 86 J.H.M. Lemmers The suitabllity of Windows NT for measurement and control purposes Chapter8 8.9 Evaluation My conclusion is that Windows is suitable for control purposes. But to achieve the highest performance, only the direct met.hod is usabie. When this method is used, Windows NT 3.51 is suitable for measurement and control purposes, if the specifications in table 8-4 are satisfying. The maximum sample rate of the system is high enough to be satistying for almost every control application. The ratio between the time needed to perform an AD-conversion and the response latency is big. The time needed to perform the conversion can be decreased by adjusting the retrieval procedure in the AdDa-driver. The system reacts predictabie. The variation can be decreased by minimising or avoiding disk access, during control operations. This can be done by logging for example to RAM and to log to disk after the control operation is completed. Also the placement of a second processor on the mother-board, will decrease the variation. A multi-processor system is able to spread the interrupts over the processors. Another possibility is to use a real-time operating system with smaller delay times and a better predictability. A disadvantage is that the contral functionality must be implemented in the device driver, which is difficult to debug and to test and much more sensitive for errors, than an implementation in a protected process. 8.10 References [ 8-1] Karl J. Aström and Bjom Wittenmark Computer Controlled Systems : Theory and design Prentice Hall International Editions, 1984, ISBN 0-13-164302-9 [8-2] Stuart Bennet Real-time computer control ; An introduction ; second edition Prentice Hall International Editions, 1994, ISBN 0-13-764'176-1 [8-3] Intel Pheripher Components 1993 ; data sheets Intel, page 3-83 to 3-99,1993, ISBN 1-55512-181-0 Page 87 Chapter 8 The suitability of Windows NT for measurement and control purposes J.H.M. Lemmers Page 88 J.H.M. Lemmers Development of the measurement and control application (MeCon) Chapter 9 9. Development of the measurement and control application (MeCon) 9.1 Introduction The last part of this master thesis reports the development of a MEasurement and CONtrol application {MeCon applicatiorl}. The MeCon application is a framework to execute and to observe a controller and to collect process data. The test setup created offers the members of the measure and control group the possibility to develop in short time and with minimal efforts software applications, to perform measure and control tasks. The application provides a frame, capable to run a specific control algorithm. The functionality of the MeCon-application must contain: • functionality to sample periodical input-values, run an algorithm and send new output values to the process to control • a good and predictabie real-time behaviour, within established specifications • a mechanism to insert an algorithm developed in an easy way • an user friendly interface, to operate the application and the contral operation, using the Graphical User Interface (GUl) • functionality to log relevant data to disk. This data can be used to analyse the control action. 9.2 Analysis of the MeCon application Figure 9-1 contains the context diagram of the MeCon application. The applications has to communicate with the operator and the process tocontrol and has to store data to disk. The computer system is connected to the process to control with analogue input and output connections. The MeCon-application is able to log data to disk and the operator is able ta start and stop the control-action, input setpoints and parameters and to observe online the contraI action. flgure 9-1 MeCon-application's context diagram Page 89 Ghapter 9 Development of the measurement and control application (MeCon) J.H.M. Lemmers On the basis of this context diagram and the required functionality, the first level of the MeGon· application is derived (see figure 9-2). The periodical process is performing the sample routine and is periodically started. Every sample cycle the Input-values are retrieved,the control algorithm is ran and the output values are sent to the AdDa-board. The sample-data is placed in the datachannel and actual sample data is temporally stored, so the dialogue pracess is able to retrieve process-data to display at the screen. The datastore pracess reads the sample-data from datachannel and writes relevant information to the disk. Because the datachannel is abIe to buffer data temporally, this process runs a low priority. The datachannelis a datastore, able to hold data, until the datastore is able to retrieve data from the datachannel to log to disk. If the system is temporally overloaded, the datachannel has the capacity to store the sample data. The dialogue process takes care of the processing of the operator communication. This com munication contains start, stop and close commands, setpoints and parameters. These commands, setpoints and parameters are passed to the periodical process. Furthermore the dialogue visualises the present state of the control operation. To imprave the real-time behaviour of the system, it can be extended with the functionality to let the datachannel store all the log data, until the control operation is ended. When the contral operation is ended, the datastore process is started, to log the data to disk. An advantage of this strategy is that the disk will not influence the real-time performance. operator figure 9-2 First level analysis of the MeGon-application Page 90 J.H.M. Lemmers Development of the measurement and control appllcatlon (Meeon) Chapter 9 9.3 Design of the MeCon application The next step is to adjust the design to the used operating system and hardware and to optimise it. The first adjustment is to introduce the device driver. In chapter 8 is concluded that the real time part must be performed by a device driver. The real-time part consists of retrieving the samples, running the control algorithm and sending the output values. After the sample cycle is executed, the device driver passes relevant process data to the periodical process. The sample routine is initiated by the hardware counter/clock, placed at the AdDa-board. The board generates an interrupt, resulting in the caU of the interrupt service routine (ISR) of the device driver. This ISR contains the functionality to perform a sample cycle. The crock has a frequency of 5MHz. By loading the counter with the right value, the board generates an interrupt at the right moment. The AdDa-board is programmed by the device driver, to generate interrupts with a frequency of 10KHz. The ISR contains a counter mechanism, so that the sample rate is adjustable to every value, which is a divisor of 10Khz. The advantages of this method is that: • it is not necessary to reprogram the clock, every time the sample rate is changed. This reprogramming is a quite difficult action. • the sample rate is easy to adjust by the software. Every device driver is running in kemel mode (or privileged mode), which means that there is no way for the operating system to monitor this code or to proteet memory from being acces sed, as is the case with user-mode code. The other parts of the MeCon-application are running in user-mode (or protected mode). The periodical process retrieves the sample data from the device driver and places this information in the datachannel. This process contains the actual process-data, available for the dialogue process to put on the screen. The periodical process is running at the highest priority level, to be sure that the sample routine is executed at once, without any additional delay, when one is started. The datachannel is a ring-buffer, including a read- and a write-function. The process executing a read-function on an empty buffer stays asleep, until data is written to the buffer. These functions contains semaphores to guarantee correct functioning. The ring-buffer uses an array to store the data. process data figure 9-3 The design of the MeCon-application Page 91 Chapter 9 Development of the measurement and control application (MeCon) J.H.M. Lemmers The MeCon-application is implemented with C++ using Windows NT as operating system. The next step is introducing classes. The main classes are visualised in figure 9-4. These classes are: • MeConApp This object is started first by the operating system. The only task of this object is to create and start a dialogue, the MeConDlg. • MeConDlg the MeConDlg is the most complex object of the application. First it puts the dialogue screen on the screen, after which it creates and starts the DataChannel, the DataStore thread (and so automatically the DataStore-object), and the AdDaDriver. When all these parts are started, the MeConDlg is waiting for input from the operator to pass to the other objects. And every 100ms it is retrieving actual process-data form the AdDa-Driver. The MeConDlg supports the states 'initialisation', 'idle', 'running', 'ended' and 'error'. • AdDaDriver The AdDaDriver is the interface of the MeCon-application to the device driver. When this object is created, it loads and starts the AdDa device driver. Furthermore it passes commands to the device driver. When the control operation is started, the DriverScan thread is started, which is responsible for reading the sample data from the device driver and to pass this to the DataChannel. This is done by a different thread, because when a read-operation is started, a thread is blocked until the read-operation is finished. So two threads are needed, one thread to read the data from the device driver and one to pass commands and to stop the DriverScan thread. • DriverScan The DriverScan thread is responsible for reading the sample data from the device driver and to pass this to the DataChannel. • DataChannel The DataChannel is an object, performing a buffer between the DriverScan and the DataStore. It supports a read and a write operation and the elements are put in an array. • DataStore The DataStore object is an independent thread, responsible for reading sample-data from the DataChannel and log relevant data to disk. So the application uses three threads, the main Dialogue-thread, the Datastore-thread and the DriverScan-thread. log data Disk I I Object C) Additional thread Data/low from A-a AloB MeconApp A·•••••••.... B Acreates 8 figure 9·4 Relation between the objects and the threads Page 92 .H.M. Lemmers Development of the measurement and control appllcatlon (MeCon) Chapter 9 The device driver contains the following main functions: • the driver entry 'DriverEntryO' The driver entry is automatically called by Windows Nrs 1/0 manager when a device driver is started. It reserves memory for the device driver's extension, it instalIs the interrupt service routine (ISR) and the DPC and other functions and it initiates the variables. • the ISR 'AdDaISRO' the Interrupt Service Routine (ISR) is called when the AdDa-board generates an interrupts to start a sample cycle. The JSR cancels the interrupt, retrieves samples and sends the new output values to the board. The last action is to start the DPC. • the DPC 'AdDaDPC' The Deferred Procedure Call (DPC) is an extension to the ISR, running at a lower priority. The DPC checks if a read-operation is carried out, waiting for sample-data. If a request is pending and placed in the system queue, the sample information is placed in the read buffer and the request is finished. • the control function 'AdDaControl' The control function handles the read- and write- calls. The write-calls are calls to pass new setpoint, parameters and commands. These calls are immediately processed and finished. The read operations are requests for process-data. These requests are finished by the DPC, when a sample cycle is executed. Therefore these read-request are put in the system queue. 9.4 Implementation The MeCon-application is implemented in C++, using Microsoft's Visual C++ 2.0. The Microsoft Foundation Class (MFC) is used as base for the main classes (see appendix F). These classes are the CMeConApp class, the CMeConDlg class and the threads. The part running in protected-mode, can be compiled and debugged using the Visual C++ environment. The MeCon-application is placed in the 'MeCon'-directory. The device driver is implemented with the Device Driver Kit (DOK). The DOK is using the language C. In appendix G the structure and implementation of a device driver is explained. The device driver can be compiled and binded by starting the batch file 'b.bat' in the AdDaDrv directory. When the compile operation succeeded, the new 'AdDaDrv.sys' must copied to the system directory with the batch file 'c.bat'. The AdDa device driver is placed in the 'AdDaDrv' directory. To debug device drivers, two Windows NT machines are needed. The AdDa-device driver isn't programmed without direct debugging, but by reading error-statuses with a read-command. The MeCon-application is tested used a controller with the function : H(z)= 1 Page 93 Chapter 9 Development of the measurement and control appllcatlon (MeCon) J.H.M. Lemmers 9.5 Inserting an algorithm The control algorithm is placed in the function 'AdDaRunAlgorithmO' (in the file 'algorthm.c'). This function is called by the ISR. An algorithm developed must be placed in this function. Variables, which are needed by the algorithm and which must be available over more then one sample or which must be passed to the part which runs in user-mode space, must be placed in the device extension of the device driver. The extension is a block of memory, which is passed to a device driver function every time it is called. In the extension the device driver puts variables which are needed over more then one call. The structure of the extension is defined in the structure 'ADDA_DEVICE_EXTENSION' in the file 'addadrv.h'. These variables must be initiated in the function 'AdDalnitAlgortithmO', which is automatically called by the device driver. The sample-values and the output-values are also placed in the extension. When algorithm-data must be passed to the user-part to be logged to disk or to be displayed on screen, this data must be placed in the ADDA_READ_BUFFER (file 'common.h'). The function 'AdDaReadAlgorithmO' makes a copy of these data from the extension to the buffer, 50 this function has to be extended. Also the function 'fScanThreadPassDataO' must be extended to copy the data from the read-buffer to the 'DataElement' object and in the class CDataElement the variables must appended. The last action is to adjust the function 'CDataStore::Handle_Sample()' to log the variables to disk. To put additional data on screen, the CAdDaDriver class and 'fScanThreadPassDataO' must be adjusted in a way 50 that data is temporally stored in the CAdDaDriver and the CMeconDlg class must read this data and put it on screen. 9.6 Conclusion The MeCon-application is suitable for measure and control purposes, if the specifications measured satisfies the demands of the afgorithm developed. It satisfies the request demands. It contains a framework, which provides the developers of a contral algorithm the opportunity to . control a process and to check the algorithm in an easy way. When developers request that additional information must be logged to disk or must be placed on screen, knowledge about programming Windows NT programs is requested. First knowledge is requested about object-oriented programming, about GUI-programming and about program ming device drivers. The program is now usabie, but the combination Windows NT and the device driver have the potential to be extended to a more complex application, performing any task within the real time specifications. 9.7 References [ 9-1] Windows NT Device Driver Kit (DOK) ; The Kemel·mode Guide (chapter 1 to chapter 16 ) The DOK containing a compiler, gives of examples device drivers, which are very useful and Iiterature about writing device drivers. [ 9-2] Microsoft's Software Development Kit (SDK) The Software development kit contains manuals of almost all Microsoft products including Win32- and MFC-programming, technical articles from many different magazines and update information from Microsoft. Page 94 J.H.M. Lemmers Evaluation Chapter 10 10. Evaluation and recommendations Developing and programming real-time applications is, because of the time factor, a difficult task. The time constraints are difficult to record in the specifications, analysis, design and im plementation and they increase the complexity. Other examples of the difficulties of real-time programming are debugging and testing of real-time software. Because the real-time character of the application and its environment, it is not possible to stop or step through the program. The measurement and control group has the opportunity to use a real-time operating system or the general purpose operating system, like Windows NT. Windows NT will satisfy the needs of the members of the group, if the specifications measured satisfies the demands. An advantage of Windows NT is possibility to combine the measurement and control application with Matlab, spreadsheets, word processors and other supporting applications. And Windows NT is al ready used by the measurement and control group and no knowledge is needed of a new operating system. The specification and the predictability of a real-time operating system will be better, but close to Windows NT's specifications. When these are not satisfying, probably those of a real-time operating system will not satisfy as weil, and a DPC system must be used. The MeCon-application is useful for testing and running control algorithms, developed by the members of the measurement and control group. Inserting only an algorithm is not a complex action. The application has the potential to be extended supporting almost every functionality required, which is needed by a specific process or controller. Because time Iimitations, I was not able to develop and insert a real control-algorithm. A proposal for a continuation of this master thesis is to develop a controller, inserting this controller in the MeCon-application and adjust this MeCon-application, 50 it satisfies exactly the demands. This includes optimisation of the retrieval of the input samples. In order to make adjustments to the MeCon-applications, knowledge is requested on C, C++, object oriented programming, Windows NT programming, the MFC, device drivers, syn chroni sation and critical areas. Fortunately I had experience with almost all of the above, but when you are only familiar to a few, it will take a lot of efforts before you are abIe to see through, and make adjustments to the MeCon-application. When I take a retrospective view back on the period I spent to this master thesis, I have to conclude it was a very interesting and instructive period. This master thesis gave me the opportunity and the freedom to increase my knowledge in field of work I want to start my carrier. A speciality with a high practical character and under increased attention of the busine!?s at this moment, because of the strong increase of the market of embedded and real time applications. Page 95 Chapter 9 Development of the measurement and control application (MeCon) J.H.M. Lemmers Page 96 J.H.M. Lemmers Appendices Appendix A Summary real-time operating systems specifications Operating system Chorus ' , iRMX 059 ;.. , 'y._•.'--.----_. - ~ - --" - - Developer Chorus Systems Intel Cooperation Microware Systems Corp. 6, avenue Gustave Eiffel 19900 N.W. 1141h Street 78182 Saint-Quentin-en- Des Moines, Yvelines France voice : (515)-224-1929 voice : +33-(1).30.64.82.00 [email protected] Contact in the Intel Benelux B.V. PEP Modular Computers Netherlands M Meesweg93 ( dhr. De Louw) 3068 AV Rotterdam Postbus 9712 . voice : 01~407.11.11 4801 LV Breda voice : 010-286.61.11 voice : 076-521.79.57 voice : 06-022.49.39 WWW-paQes www.intel.com www.microware.com Type of operating Host-target Stand-alone Stand-alone system Supported hardware Host: intel386, intel486, Pentium mc680xO • UNIX (SUN) Target: • Intel 1960 and 386/4861 Pentium • PowerPC • mc68030, mc68360, mc68040 • mc88K • SPARC • transputer T425fT805fT9000 Development tools standard 32-bit C-compiler standaard C and C++ and debuaaer compiler and debuaaer Supporting CASE-tooi Intel reports that no CASE- tools are known Network support compatible with most dos • TCP/IP networks • Novell/lPX • TCP/IP • and more • NovelI netware • and more Price Remarks Is able to run Dos and • based upon UNIX Windows applications as • OS9000 is the Intel- task processor version of OS9, but is not stabie enough and hardlv used. page 97 Appendices J.H.M. Lemmers :::~,";:;J Operating·system::+.~~%,,; ·,"j;lJ%tx'C> '•• QNX~'>iYli;,§~~;:i (' I ,'," ~j7'-;-,~' "w, ";;~~ ,'f"_:;-»::~~.\':'-:~t!_i>.';'~, I~~;;,~q;ó:,~~,., ,,~;;.li:'§. ~-~~:;{:~f;;r~::.~:(,,:_:~,;;"~·]lf'; ;:?, ..... '. i S ';;'i! .~~t'r:i:· .... '.' Developer Integrated Systems Inc. QNX Software systems Ltd. Micro Research Inc. 3260 Jay Street 175 Terence Matthews Cr. 2350 Mission College Blvd. Santa Clara, CA 95054 Kanata, Onlario Canada Sanla Clara, CA 95054 voice : 408-980-1500 K2M 1W8 Voice: (408)-980-1300 info@isLcom voice : +1-613-591-0931 [email protected] [email protected] Contact in the Anglia Technology Ltd. PEP Modular Computers Nelherlands 4 Hellesdon Hall Industrial ( dhr. De Louw) park Poslbus 9712 Norwich, England NR6 5DR 4801 LV Breda voice : +44-603-789-432 voice: 076-521.79.57 WWW-paqes www.isLcom www.qnx.com Type of operating (host-target) Stand-alone Host-target system Supported hardware Host: Intel386, Inlel486, Pentium Host: Target: • UNIX • Intel 1960 and 386/486/ • MsDoslWindows Pentium Target: • PowerPC • Intel386, Intel486 • Motorola 680xO, 683xO • Inlel960 • MIPS • mc680xO • and more Development tools Watcom C and Watcom XRAY graphical C++ compilers development tooi, including C/C++ compiler. debugger for UNIX and Windows Supportinq CASE-tooi ObjecTlm ObiecTime O~ecTime Supported networks providing location trans- • TCP/IP with NFS • TCP/IP, TCP, UDP parent interprocess com- • NovelI • stream based networking munication • Ethemet. serial Price universities : FI.9 600,- Remarks 3 versions: • VRTx 32 nanokemel • VRTxsa tor high performance kemel • VRTxmc tor microcontrollers page 98 I.H.M. Lemmers Appendices Operating system VxWorks Developer Wind River Systems 1010 Atlantic Avenue AJameda, CA 94501 USA voice: 1-510-748-4100 [email protected] Contact in the • Koning en Hartman Netherlands (Bas Bets) Energieweg 1 Postbus 125 AC Delft voice : 015-260.99.06 • PEP Modular Computers ( dhr. De Louw) Postbus 9712 LV Breda voice : 076-521.79.57 [email protected] WWW-paqes www.wrs.com Type of operating Host-target system Supported processors Host: • UNIX • Windows Target: • Inte1386, Intel486 and Pentium • Intel960 • mc680xO • SPARC • and more Development tools Tornado: a graphical development tooi, including C/C++ compiler and debuqqer Supporting CASE-tooI .ObjecTime • ObjectGEODE • SDT • ObjectTeam Supported network • TCP/IP • ???? Price • FI28 000.- • universities 50% reduction Remarks • UNIX based • MatLab's Simulink is capable to generate code forVxWorks page 99 Appendices J.H.M. Lemmers Appendix B Comparison of object-oriented methods name",:;:·",,;, .>tOOAlOOO'"'I;ç"';"ÄOMT;i·' , ..··.';<'n:OPAID~,;':n'(;:'\.ROOM ,.,', '. ..··000 ~.-:,~":'!"~;~~-~''"~'~;o" "':~_;- '1" ~ .,..... ,~ ...~~';";=~~,~='-..~~~ name Coad, Yourdon Rumbaugh and Shlaer, Mellor Booch developers' others statie models • object layer • object diagram • information • system level • object diagram • c1ass layer model • class diagram • subject layer • cJass category diaQrams dynamic • object state table • state diagram • state transitions • concurrency level • state diagrams models .message • event trace • object commu- • timing diagram connection nications model model • (subsystem eom- munication model) functional • service diagram • data flow • data flow • detail level models diagram diagram • system level implementation • Subsystems • detail level • modules diagram aspects • process diagram advantages • data modelling • Clear stages and • division of • strong relation • friendly and free diagrams objects in specification- design techni- • popular and weil hierarchy levels implementation ques results that supported and • uses traditional design is weil documented techniques supported • strong state • reusability model • easy maintained disadvantages • performance • performance • performance • performance • performance aspects aspects aspects aspects? aspects .Iess support for • no concept to • complex terms, .Iess documented • complex developers for structure the models and and weak graphical the information system diagrams support by notation modelling and for .Iess support for CASE-tools • partitioning the development message support almost process passing, exclusively for inheritance and design-phase encapsulation • weak semantic soundness page 100 l.H.M. Lemmers Appendices Appendix C Comparison of functional-oriented methods statie model • entity transition diagram • block diagram • context diaÇJram dynamic model • state transition diagram • process diagram (state machines) • MSC scenarios functional model • data flow diagram advantages • popular and weil sup- • strong description of ported and documented behaviour • acceptance in industry • strong relation between • give goed overview of specifications and system implementation • equal techniques for • suitable for validation and analyse- and design phase verification • used in the field of telecommunication disadvantages • easy of change • data model/ing • maintainability • reusability • performance-aspects page 101 Appendlces J.H.M. Lemmers Appendix D 5ummary CA5E-tools specifications \'\i;,ObjectTeam.for :,' Stiraer-Më1~lo-':r~'~",..,.".,. Company Mark V Systems Ltd. Cadre Technologies, Inc. Cadre Technologies, Inc. 16400 Ventura Blvd 222 Richmond St., 222 Richmond St.. Encino, Ca. Providence, RI Providenee, RI voice: (818)-995-7671 voice: (401)-351-5950 voice: (401)-351-5950 [email protected] Contact in the First Result Consultans • Cadre Technologies • Cadre Technologies Netherlands ( Tijmen Mekel) Postbus 5063 Postbus 5063 Comelis Schuytstraat 10-1 NL-2600 GB Delft NL·2600 GB Delft 1071 JH Amsterdam voice : 015-214.12.12 voice: 015-214.12.12 voice : 020-671.14.22 • Koning&Hartman • Koning&Hartman [email protected] (Ernst Jan Smit en Mark (dhr. Ernst Jan Smit en Jansen Roosendaal) Mark Jansen Roosendaal) Energieweg 1 Energieweg 1 NL-2627 AP Delft NL-2627 AP Delft voice : 015-260.98.89 voice : 015-260.98.89 [email protected] [email protected] WWW-oaaes www.markv.com www.cadre.com www.cadre.com Development • MS-Windows • Windows NT/Windows 95 UNIX platforms • MS-Windows NT • UNIX • various UNIX platforms Target platform • VxWorks Supported Support of more than 30 OMT extended with Shlaer/Mellor methods popular methods: subsystem facilities • 800ch • CoadIYourdon • Shlaer/Mellor .OMT • Ward-Mellor • many more methods • customised methods Code generation • dependable of method, but • SmallTalk • C++ : code-generation uses code-generation is • SOL adjustable templates adjustable • C++: code-generation uses adiustable temolates Price • FI.2 200,- to FI.50 000,- • FI.5000,- University program: • educative licence cost • university program : OOA FI.4 660,' FI.6 500,- tor complete set F1.3 695,- annual 000 FI.4 660,- Remarks • META-CASE-tool, offers • Multi-users capability • Multi-users capability extensive facilities to adjust • Koning&Hartman has or to support new methods experienees using and to adjust code ObjectTeam tor real-time generation applications and VxWorks • Users at TUE (Ron Helwig te1.2724) page 102 J.H.M. Lemmers Appendices Name ObjecTlme Object Domain Paradigm Plus Company ObjecTime Um. Dirk Vermeersch Protosoft 340 March Road, Suite 200 1397 Ridgewood Drive 17629 EI Camino Real 202 Kanata, Ontario, Canada San Jose, CA 95118 Houston TX 77058 K2K2E4 [email protected] voice : (713)-480 3233 voice: (613)-591-3400 [email protected] Contact in the Real Time SkilIs Center KISS bv Netherlands ( Bemard Dupre ) ( Eric Laane ) Paris, France Hoofdstraat 8a voice: +33-1-69.82.93.32 Postbus 505 [email protected] 5460 AM Veghel voice : 0413-35.03.30 WWW·paQes www.obiectime.on.ca protosoft.com Development • UNIX ( SUN, HP IBM, Windows 3.1 • Windows 3.1 platforms RS/6000) • Windows NT • various UNIX platforms Target Platform • VxWorks • VRTx • pSOS+ • QNX • HP-RT • UNIX ( SUN, HP, IBM RS/6000) Supported • ROOM Booch • Booch methods • CoadIYourdon .OMT • Shlaer/Mellor • customised methods Code generation • full C++ generates C++ headers and Incremental code generation: • tuil C stubs • C++ • tuil SmallTalk •C • Ada • SmallTalk Price ($20.000 includes training Shareware, $99 ( $4000-$7700 ) and support ) Remarks • specialised in real-time Demos available • META-CASE-tool software • Paradigm Plus is con- tiQurable and customisable page 103 Appendices J.H.M. Lemmers i~~~E1~I;~r:'J~~~~1~0;~~;~~~ij~?~~,~:~~~:~t~i~~~~1~~_~i;~~~~~~~,~L~rr~~~o~~>,çtt~!:~':mi~;7;,:~jt;::::jS~'f;';...... •. Company Debis Systeemhous Rational Rose Telelogic AB 3320 Scclt Blvd. Box 4128 Santa Clara, Ca. 95054 S-203 12 Malmö, Sweden voice : (408)-496-3700 voice: +46-40.17.47.00 produkt [email protected] e-mail: [email protected] Contact in the Bergson Technology bv Netherlands Brussellaan 7c Postbus 1519 5602 BM Eindhoven voice : 040-242.34.14 WWW-paaes www.rational.com www.telelogic.se Development Server: UNIX • UNIX • UNIX (SUN, HP, IBM platforms Client : UNIX and Windows • Windows 3.1 195 RS/6000, DEC) • Windows NT • Windows 3.1 (no simu la- tion and validation facilities) Target Platform • VxWorks • VRTXsa • (Chorus) • pSOS+ 2.0 Supported • Structured analysis (SA) • Booch • SOL and MSC methods according to .OMT •( SOMT: and combination Yourdon/DeMarco •( Unified Method ) of SOL + MSC and OMT ) • real-time extension to SA according to Hatley/Pirbhai • data modeling according to the Entity-Relationship methodoloqy Code generation • forward and reverse • C++ • full C engineering for the C- • SmallTalk (Rational Rose language SmallTalk) • ADA ( Rational Rose ADA ) Price • 4*FI.3900,- per module • University :a few thousand qulden Remarks • Multi-users capability • Multi-user capability • Multi-user capability • Reverse C engineering • Reverse CH engineering • Specialised in real-time en • offers a large family of embedded software development tools, like a development development-tool providing • Extensive Validation and real-time support for simulation facilities embedded systems • Booch and Rumbaugh are fellow-workers of Rational and are working on a new method called Unified Method page 104 J.H.M. Lemmers Appendices Name SelectOMT System Architect System Oevelopment Workbench (SOW) •••• Company Select Software Tools Ltd Popkin Software CAP Volmac BV 1526 Brookhollow Dr. 11 Park Place Daitoniaan 100 Santa Ana, CA 92705 New Vor!<, NV 10007 Postbus 2572 voice: (714)-957-6633 voice: (212)-571-3434 3500 GN Utrecht voice: 030-252.68.90 Contact in the Lemax R.T.S. ( dhrWestra Netherlands Postbus 263 Rijnzathe 7B-3 voice : 030-252.71.69 ) 1170 AG Badhoevedorp 3454 PV De Meern voice: 020-659.87.01 voice : 030-666.55.30 WWW-paaes Development • Windows • Windows • MsDos platforms • OS/2 • MsWindows 3.1 Taroet platform Supported .OMT • Booch SDW methods .OMT extendible with modules tor: • CoadIYourdon • structured design • Shlaer/Mellor • data rnodelling • WardiMellor • tunctional analysis • state transitions Code generation • C++ • generation ot C++ header • and skeleton code Price ($695 ) • FI.4 000,- to Fl.15.000,- • FI.5500,- tor every module • FI.5 000,- university offer ( a working system needs, several modules) • universities: 40% reduction Remarks • strongly moduJar • multi-user capability • reverse C++ engineering • strongly modular • special real-time modules page 105 Appendices J.H.M. Lemmers r~;~ObJeètGEO.DE.(L.OY;,OMTd~lObjectGEODE/itOY:OMTt~f4~)~~~vnR~iflt"'C~SE~MT ,'~~~~:':'~r~~_1;~<~:;~~~;-;~' :t;;;·;ir,~~j:0f~~~:t~~~~: ~'k~~;~~{'~~~~~~ n::~~~;;~~1:;:'~;~~~;~~)~t~~:~~~~j:':,',~~?~l}~~{~~;:::::i~~; ,<ànd I.;(:ASE ShlàerlMellor Company Verilog Inc. Verilog Inc. Westmount Technology b.v. 3010 LBJ Freeway, Suite 900 3010 LBJ Freeway, Suite 900 Olof Palmestraat 24 Dallas, TX 75234 Dallas, TX 75234 Postbus 5063 voice : (214)-241 6595 voice: (214)-241 6595 2600 GB Delft [email protected] [email protected] voice: 015-141212 [email protected] Contact in the Real Time Skills Center Real Time SkilIs Center Netherlands Bemard Dupre Bemard Dupre Paris, France Paris, France voice : +33-1-69.82.93.32 voice : +33-1-69.82.93.32 [email protected] [email protected] WWW-pages www.verilogusa.com www.verilogusa.com http://www.qucis.queensu.cal Software-Engineeringlblurbl Westmount.html Development • UNIX (SUN, HP, DEC • UNIX (SUN, HP, DEC • UNIX platforms platforms Alpha and IBM RS6000) Alpha and IBM RS6000 ) Target platform • VRTx 32 • VRTx 32 • pSOS+ • pSOS+ • VMS • VMS • and more • and more Supported SDLand MSC OMT .OMT methods • Shlaer/Mellor Code generation full C full C++ C++ (OMT) C( WardlMellor ) Price The tools are sold in pack- ages or separately and will be priced beginning at $11.000. . Remarks • multi-user capability • multi-user capability other products : • specialised in real-time • specialised in real-time • Westmount I-CASE software development software development SSADM • strong validation and • strong validation and • Westmount I-CASE verification facilities verification facilities Yourdon • reverse C++ • reverse C++ engineering • Westmount I-CASE OMT • extensive validation and • Verilog tool's Logiscope, specialised in client-server verification facilities enables software quality applications • Verilog tool's Logiscope, certification and test • Westmount I-CASE enables software quality evaluation SSADM certification and test evaluation page 106 J.H.M. lemmers Appendices Appendix E Windows NT Introduction In 1988, Microsoft started developing a new operating system tor the 1990s. The result is Wi ndows NT. Windows NT is a preemptive, multi-tasking operating system that allows multiple process to run within the system at the same time. Windows NT is designed tor a variety ot CPUs and on single and multi-processors systems and is strongly related to VMS. Windows NT is suitabfe tor i80386/486 and Pentium, Alta- and PowerPC-processors. The tollowing are the Windows NT design goals: • Extensibility The code muse be written to comtortable grow and change as market requirements change • Portability As dictated by market goals, the code must move easily trom one processor to another • Reliability and robustness The system should proteet itselt trom both internal maltunction and external tampering. It should behave predictably at all time, and applications should not be able to harm the operating system or it tunctioning • Compatibility Although Windows NT should extend existing technology, its user interface and APis should be compatible with existing Microsoft systems. • Performance Within the constraints ot the other design goals, the system should be as tast and responsive as possible on each hardware platform. Windows NT provides a graphical user-interface, based on Windows 3.x. In summer 1996 a new version will be introduced, supporting a the graphical interface based on windows 95. Microsoft recommends Windows NT as a network server, so Windows NT is equipped with extensive network facilities. Windows NT is able to run Windows 3.1 programs, DOS programs and Win32 programs, like programs tor Windows 95. Because Microsoft hired developers trom Digital Equipment Corporation, where they were responsible tor developing VAXNMS operating system, Windows NT is c10sly related to VAXNMS. page 107 Appendices J.H.M. Lemmers Structure of Windows NT The structure of Windows NT can be divided into two parts (see figure E-1): -. the user mode portionof the system (theWindows NT protected subsystems) • the kernel-mode portion (the NT executive). Windows NT servers are called protected subsystems, because each one resides in a separate process whose memory is protected from other processes by the NT executive's virtual memory system. As the term 'server' implies, each protected subsystem provides an API that programs can call. When an application (or another server) calls an API routine, a message is sent to the server that implements the APr routine via the NT executive's Local Procedure Call' (LPC) facility. Examples of these protected subsystems are OS/2 subsystem, Win32 subsystem, POSIX subsystem, networking services and printer ser;vices. Applications Protected Subsystems (servers) ... w .: r System services 5 . Local V' I 110 Manager Ob' t ecunty P Procedure Irtua lec Reference rocess Memory NT Executive Manager Monitor Manager CaU Manager .cn. 1l.I.".~1 Faclilty ~'.\fce Orlv.r_, .r.ortl unvel Kemel Message Passing . , I1 Hardware Abstraction Layar (HAL) I I I I I I II System Trap I I ------. t y t t Hardware manipulation Hardware -----~ figure E-1 Windows NT block diagram The Executive is the kernel mode portion of Windows NT and, except for a user interface, is a complete operating system into itself. The executive consists of a series of components, each of which implements two sets of functions: • system services, which environment subsystems and other executive components can call • internal routines, which are available only to components within the executive. page 108 J.H.M. Lemmers Appendices These components are: • Object manager Creates, manages, and de/etes NT executive objects, abstract data types, that are used to represent operating system resources. • Security reference monitor Enforces security policies on the local computer, It guards operating system resources, performing runtime object protection and auditing. • Process manager Creates and terminates processes and threads. It also suspends and resumes the execution of threads and stores and retrieves information about NT processes and threads. • Local Procedure CaU (LPC) facility. Passes messages between a client process and a server process on the same computer. LPC is a flexible, optimised version of Remote Procedure Cal (RPC), an industry standard communication facility for client and server processes across a network. • Kemel Responds to interrupts and exceptions, schedules threads for execution, synchronises the activities of multiple processors, and supplies a set of elemental objects and interfaces that the rest of the NT executive uses to implement higher-level objects. • I/Osystem Comprises a group of components responsible for processing input from and delivering output to a variety of devices. The 1/0 system includes the following sub-components: o 1/0 Manager Implements device-independent inpuVoutput facilities and establishes a model for NT executive 1/0 o File systems NT drivers that accept file-oriented 1/0 requests and translate them into 1/0 requests bond for a particular device. o Network redirector and network server File system drivers that transmit remote 1/0 requests to a machine on the network and receive such requests, respectively. o Device drivers Low-Ievel drivers that directly manipufate hardware to write output to or retrieve input from a physical device or network. An example of a device driver is the AdDa device driver to control the data acquisition-board. o The cache manager Improves the performance of file-based 1/0 by storing the most recently read disk information in system memory. The cache manager uses the VM managers paging facility to automatically write modifications to the disk in the background. Processes and threads In Windows NT, a process is a running instanee of an application. A process consists of code loaded from an executable and data including global and statie variables. A process a\so owns other resources such as filed, dynamic memory allocation and threads. Each process maintains a private address space to ensure that it wiJl not interfere with other processes. A process owns a set of system resources as files, pipes, communication ports and semaphores, that the operating system allocates as the process executes. All processes must have at least one thread. There is no limit, other than memory on the number of threads a process can own. A thread is a unit of execution in an application. Each thread is associated with a sequence of CPU instructions, a set of CPU registers and a stack. In Windows NT, a process can contain several threads. Each thread gets CPU time by the Windows NT kemel. page 109 Appendices J.H.M. Lemmers A context switch is the procedure of saving the volatiIe machine state associated with a running thread, loading another thread's volatiIe state, and starting with the new thread's execution. The module that performs these duties is the kernel's dispatcher. A thread's context and the procedure for context switching vary depending on the architecture of a processor. A typicat context switch requires saving and reloading the following data: • program counter • processor status register • other register contents • user and kemel stack pointers • a pointer to the address space in which the thread runs (the process's page table directory) Schedullng and priorities The unit of scheduling is a thread, The Windows NT scheduler is unaware of processes for the most part. On the other hand the priority mechanism is strongly process oriented. One property of every process is the priority-class, for example real-time class. The priority class defines the basic priority at which the application wil! run. Windows NT includes 32 priority levels of which the levels 16 to 31 are reserved for the operating system and real-time processes (see figure E-2). Every process (and his threads) is assigned to one priority class, in figure E-1 represented by a single column. Each thread has a current priority that is derived from the process' priority class. Threads are scheduled according to their priority. When the kemel is choosing which thread will execute on a processor, the highest dynamic priority thread is picked. When a thread is scheduled, it is given a quantum of time in which to run. The system currently uses quantum of 15ms (on x86 processors). Priority inversion can occur when a high priority thread can not continue, because a low priority thread has a lock on a critical area. However the low priority gets no access to the processor, because a medium priority thread. The Windows NT scheduler solves this problem by randomly boosting the priority of threads that are ready to run. This facility decreases priority inversion, because low priority threads run long enough to let go exit a critical area and the high-priority thread is abIe to enter the critical area. Windows NT is build around a virtual memory system, but paging 1/0 occurs at a lower level than the real-time priority process levels. So virtual memory management will not interfere with processing at real-time priority. Processes are permitted to loek itself into memory, so they are always available in physical memory. Furthermore processes are allowed memory mapping, which permits multiple processes and device drivers to share the same physical memory. page 110 J.H.M. Lemmers Appendices ·_-Ä-~~~ti~~ti~~~~rit~I-~\ii------·---·---·------Fië-á~tin;e;-ëiás-së-s~ i':26l' :1\.25" Real·time normal:'24": 23 :...22..- : Real·time idle .m : f;~~:~~;~~~~~;~::;~~:;-~ritl~~;f~~~;l::~~~~::=:::::::::::::::[));~~~i~:~I~~~~~1 I >14/,- : : 13 - High foreground f3' : : 12' : : 11 ;«1tik : : :0:'0< : : 9 - NOrmalfOregroUnd::-' r.;?".:"~.'.;.l : : 7 5:7!" : o • 0 : 7 • Normal background . 6 : : 5: o , : ' o, ,• : 2: : 1 - Non'real-timelidle [TI : : 0 - Idle lhread D:J : I.~ -._------• •• figure E·2 Windows NT priority classes Windows NT handles interrupts on a preemptive basis. When an interrupt occurs, all execution at lower interrupt levels is suspended and execution begins immediately on the highest-Ievel request. The kemel supports twenty-four interrupt-levels. Devices are handled by device drivers (see Appendix G). These consist of an initialisation routine, an interrupt service routine (I SR), deferred processing calls (DPC) and system threads. Processing in a device driver will proceed to completion without any interruptions. An ISR can be interrupted by another (SR with higher priority, one of the reasons that interrupt latency is hard to def;ne for Windows NT. A DPC handles the non-time-critical processing for the driver at a lower priority-Ievel. Asynchronous 110 is also supported, so an application can queue 110 and continue processing without having to either wait or respond immediately to some end-of-I/O event. Finally, there is a single system process, within which there can be multiple system threads. This system process runs all device drivers, the kemel, the executive, and device drivers. All of these components share a single address space, called 'system space'. The kemel The kemel performs the following tasks: • schedules threads for execution • transfers control to handier routines when interrupts and exceptions occur • performs low-Ievel multiprocessor synchronisation • implements system recovery procedures after a power failure occurs. The kemel always runs in kemel mode, Windows Nrs privileged processor mode, and is designed to be smaU, compact, and as portable as performance and differences in processor architectures allow. The kemel is never paged out of memory. Similarly, although it can be interrupted to execute an interrupt service routine, its execution is never preempted. page 111 Appendices J.H.M. Lemmers The 1/0 system The NT executive's 1/0 system is a collection of operating system code that accepts IlO requests from user-mode and kemel-mode processes and delivers them, in a different form, to IlO devices. Between the user-mode services and the mechanics of IlO hardware lay several discrete system components, including full-blown file systems, numerous device drivers, and one or more network transport drivers. The goal of the IlO system is to provide a virtual interface to IlO devices that allows programmers to simply retrieve or store data without concern for the behaviour of individual devices. But it also must accommodate the needs of existing devices, from a simpIe mouse to keyboards, printer, graphic display terminals, disk drives, CD-ROM drives and networks. The IlO system is packet driven, which means that every 110 request is represented by an 1/0 Request Packet (IRP) as it travels from one 1/0 system component to another. An IRP is a data structure that controls how the IlO operation is processed at each stage along the way. The IlO manager defines an orderly framework or a model within which IlO requests are delivered to file systems and device drivers. In Windows NT, programs perform 110 on virtual files, manipulating them by using file handles. All potential sourees or destination for 110 are represented by file objects. User-modethreads call native NT file objects services to read from a file, write to a file, and perform other operations. The IlO manager dynamically directs these virtual file requests to real.files, to file directories, to physical devices, to pipes, to networks, to mailslats and to any destinations that are supported in the future. The IlO model can be single-Iayered. With such model, an IlO request passes to the IlO manager and then to the device driver, which communicates directly with the device (see figure E-3). A multi-Iayer driver, in which a request passes through two or more drivers during its processing. Appendix G contains more information about device drivers. System services I System services File System .... Drivers 110 ~ ~"',~~,. 110 manager ; 9'anager Device Device ~ .. ' Drivers Drivers ..". 1 Hardware I , single-Iayered driver mutti-Iayered driver figure E-3 IlO to a single-Iayered and a multi-Iayered driver page 112 J.H.M. lemmers Appendices Interrupt and Exceptlon handling Interrupts and exceptions are operating system conditions that divert the processor to code outside the normal flow of control. They can be detected by either hardware or software. When an interrupt or an exception is detected, the processor stops what it is doing and transfers control (dispatches) to a speciallocation in memory, the address of the code that deals with the condition. In NT, this code is called the trap handier. An interrupt is an asynchronous event, one that can occur at any time, unrelated to what the processor is executing. Interrupts are generated primarily by IlO devices, processor clocks, or timers. An exception is a synchronous condition, resulting from the execution of a particular instruction. Examples of exceptions include memory access violation, certain debugger instructions, and divide by zero errors. Hardware-generated interrupts typically originate from IlO devices that must notify the processor when they need service. Interrupt-driven devices allow the operating system to get the maximum use of the processor by overlapping central processing with IlO operations. The term trap refers to a processor's mechanism for capturing an executing thread when an exception or interrupt occurs, switching from user mode into kemel mode, and transferring control to a fixed location in the operating system. When a software or hardware interrupt is generated, the trap handier is activated. The trap hander disables interrupts briefly while it records the machine sate (information that would be wiped out if another interrupt or exception occurred). It creates a trap frame in which it stored the execution state of the interrupted thread. This information allows the kernel to resume execution of the thread after handling the interrupt or the exception. The tap frame is usually a subset ot a thread's complete context. A sub-module of the kemel's trap handier, called the interrupt dispatcher responds to interrupts. It determines the souree of an interrupt and transfers control either to an external routine that handles the interrupt, called an interrupt service routine (ISR) or to an internal kemel routine that responds to the interrupt. The interrupt dispatcher maps hardware-interrupt levels onto a standard set of interrupt request levels (IROl) recognised by the operating system. IROls rank interrupts by priority. An IROl is an attribute of an interrupt source, sueh as a keyboard or a mouse. The IROls, trom high level down to level 1, are reserved for hardware interrupts, and dispatchlDPC level and APC level interrupts are software interrupts that the kemel generates (see table E-1 and table E-2). The low IROl is not really an interrupt level at all. It is the setting at whieh normal thread execution takes plaee and all interrupts are allowed to occur. Interrupts from a source with an IROl above the eurrent setting interrupt the processor, whereas interrupts from sources with IROls equal to or be/ow the current level are blocked, or masked until an executing thread lowers the IROL. page 113 Appendices J.H.M, Lemmers tabIe E-1 Interrupt Request levels (IROls) IRQl Type of Interrupt Hioh level Machine check or bus error Power level Power failure Inter-processor interrupt level Work request from another processor Crock level Interval clock Device level n Hiqhest-prioritv IlO device (see table E-2) ... '" Device level 1 lowest-prierity IlO device (see table E-2) Dispatch/DPC level Thread dispatching and deferred procedure call (DPC) processinq APC level Asynchronous procedure caU (APC) proces:;ing low level Normal thread execution When an interrupt occurs, the trap handier saves the table E 2 l'ISt0 f har dware In. terrupl s machine's state and caUs the interrupt dispatcher. Inter - interrupt dispatcher immediately raises the processor's Interrupt Type of interrupt IROl to the level of the interrupt source to mask ReQuest interrupts at and below that level while interrupt (IRQ) servicing is in progress. Windows NT uses an interrupt IROO timer dispatch table (lOT) to locate the routine to handle a IR01 keyboard particular interrupt. The IROl of the interrupting IR03 COM2 source serves as a table index, and table entries point IR04 COM1 to the interrupt-handling routines. IROS lPT2 IR06 flo~py-drive After the service routine executes, the interrupt IR07 LPT1 dispatcher lowers the processor's IROl to where it was IR08 reaI-time clock before the interrupt occurred and then loads the saved IR010 reserved machine state. The interrupted thread resumes IR011 reserved executing where it lefts off. When the kernellowers IR012 reserved the IROl, lower-priority interrupts that were blocked IR013 coprocessor might materialise. If this happens, the kernel repeats the process to handle the new interrupt. rR014 IDE-disk IR01S SCSI driver The kernel can disable interrupts so that the processor does not receive them, but it does so only infrequently, at critical moments while processing an interrupt of dispatching an exceptien, for example. Synchro,nlsatlon The kemel has a set of dispatch objects, to aUow processes and device drivers to synchronise and to communicate. Included in this set are various timers, events, mutexes, pipes, mailboxes, semaphores and spinlocks. Spinlocks are a method to ensure synchronisation, by locking a global data structure that ensures that only one thread can get access to that data at any one time. The timer resolution is depending on the hardware. For Intel-based CPU's, the resolution is about 15msec and can be highly influenced by ather operations performed by the computer. Windows NT offers facilities to read out the system timer, providing a resolution of O.8Jl.S. Messages Windows NT is, Iike all Microsoft's Windows p~atforms, message oriented. A message is posted by the operating system or a program to notity a specific window to perform a task. The application's message handier retrieves the message and dispatches it to the appropriate window procedure. Examples of such message a notification a button is pressed, a window is activated or deactivated, a key is pressed. There are system-messages and user-defined messages. page 114 J.H.M. Lemmers Appendices Wrlting Windows NT Appllcatlons Windows applications are build around two important aspects: Windows and message queue's. Every application must have at least one window. To a window is a message queue connected. For each type of messages a message-function is defined. These message-functions are called by the operating system, if a particular type of message arrives at a message queue. After an application has executed the necessary actions, the function is ended and the application is put in {blocked mode}. Performance Because the complexity of the kemel and the used scheduling policies, it is very difficult to calculate response times. In [E-1 ] these response times are measured. The paper corcluded that Windows NT was appropriate for use as a real-time system. The basic measurements are listed in table E-3. table E-3 Measured response latency (source [E-1 ]) Measurement Duration (J.l.sec] Pentium 90MHz, 16Mbyte minimum maximum hardware interrupt latencv 1.8 2.9 interrupt dispatching 4.6 10.5 interrupt service routine lenath 10.3 16.7 total elapsed time 16.7 30.1 Literature: [ E-1] Brian Catlin Design of a TCP/IP reuter using Windows NT delivered at the 1995 Digital communications Design Conference [ E-2] Helen Custer Inside Windows NT Microsoft Press, 1993, ISBN 1-55615-481-X [E-3] John M. Knoeller Writing Multithreaded Applications Microsoft Development Library. January 1996 page 115 Appendices J.H.M. Lemmers Appendix F Microsoft Foundation Class (MFC) It is not easy to develop Windows programs. Getting a simple window on the screen can take dozens oflines of complex code. Therefore Microsoft has developed the Microsoft Foundation Class (MFC) Iibrary for use with Windows. The MFC library takes full advantage of the data abstraction offered by C++, and its use simplifies Windows programming. The MFC Iibrary features classes for managing Windows objects and offers a number of general-purpose classes that can be used in both MS-Dos and Windows Applications. For example, there are classes for creating and managing files, strings, time, persistent storage, and exception handling. In combination with the appWizard tooi, a tooi included in MS Visual C++ able to generate automatically applications, the MFC provides the possibility to create a complete editor, with many windows, a menu and a button bar, containing a few lines of code. MFC makes use of a naming convention of variables: These notations are put in table F-1 Tabie F- 1 Some 0 ft h e MFC namlnQ notatIon Prefix Means Cxxx the class xxxx cxxx char pxxx pointer ixxx inteQer fnxxx function lxxx lonq Ipxxx lonq pointer Ipszxxxx a lono pointer connected to a zero-terminated strinq to strinq xxxx and many more The next MFC-classes are used: • CWinApp The CWinApp is the base of a windows application. It conneets itself automatically to Windows and it handles Windows Messages and sends them to the right window. By overriding the InitlnstanceO-function, an application's own initialisation is executed, for example the creation of a Dialog. • CDialog A Dialog represents the standard way of receiving control input from the user bevond the menu level. The look of a dialogue is designed by the Diatog editor. By calling the DoModalO function the dialog is started. The thread returns from this function when the cancel or Ok-button is pressed. The CDialog-class handjes all the input to the dialog. • CWinThread Represents a thread Books: [ F-1] Steven Holzner Microsoft Foundation Class Library Programming ;A Complete guide to power programming with Visual C++ Brady Publishing, 1993, ISBN: 1-56686-102-0 page 116 J.H.M. Lemmers Appendices Appendix G Device Drivers for Windows NT Device drivers serve several different purposes. In their purest form, they are the link between software and hardware. Normally, a device driver is part of an abstraction mechanism, that is, a software architecture that provides applications with hardware-independent, high-level access to IlO functionality while the lower hardware-dependent levels are encapsulated in the device driver. The advantage of this architecture is that no change needs to be made to the application if the hardware is changed. If an application wants to perform some kind of input of output, for example save a file to disk, it wil! submit the request to the operating system through the use of an Application Programming Interface (API). The operating system and the device drivers translate the call into something the hardware can understand. Windows NT device driver provides the next services to an application: • open operation • read operation • write operation • close operation • 110 ConTrol (IOCTL) operations, so an application is able to control a device driver, for example to control a baud rate. Like you see, in Windows NT there are very few functions to access specific device types. When an application tries to open an 110 stream (regardless of whether the 110 stream . corresponds to a file on a hard disk, a communications port, a file on a remote logical network driver) the Wi ndows NT kemel analyses the name of the stream and, employing a mechanism known as 'symbolic link' decides what driver to pass the request to. All drivers you can write for Windows NT will fall into one of three categories: • user mode drivers The user mode is the Jess privileged mode. Important user mode drivers are the'graphic driver (not a file object for performance reasons) and printer drivers. • kemel mode device drivers Kemel mode device drivers are running in kemel mode, the privileged execution mode of Windows NT. Kemel mode device drivers are the only way for any software to communicate directly with the hardware. • Virtual Device Drivers (VOOs) User-mode OLLs that aid in virtualising custom hardware to MS-DOS-based applications. Furthermore Windows NT discerns Service, a background program user-mode process that may act as a server process for all applications. For this master thesis a device driver is needed to access a analogue/digital input and output board. Because this device driver must have access to hardware, a kemel-mode device driver is developed. So now we will concentrate on kemel-mode device drivers. Like said earlier, kemel-mode device drivers are running in privileged execution mode. Privileged means that there is no way for the operating system to monitor this code or to protect memory from being accessed, as is the case with user-mode code. Thus, kemel-mode drivers had better know what they are doing, because they are trusted by the operating system. Kemel-mode can do whatever they want, including monitoring access to Windows NT system resources. Kemel-mode drivers can be layered, that is, Windows NT will pack up a user's 110 request into a data structure speeific to the 110 model ( an 110 request packet) and send the packet oft to the driver that corresponds to the device. The driver can either process the request or do something with it and pass the modified request on to another driver. page 117 Appendices J.H.M. Lemmers This is extremely useful, for example for mass storage devices. The request will initially go to a file system driver, that is, a driver that understands file systems 'such as FAT (file allocation tabie) or NTFS (New Technology file system). The request can then be passed on to an intermediate driver and can eventually be routed to a driver that accesses the physical device, possibly after having traversed even more intermediate drivers, such as mirror drivers. interface to end user other reqyesls print requesls usermode kemel mode usermode kemel mode 110 System Services Video adapter 1/0 Keyboard device Manager Peripherals and Processors Mouse device Parallel port flgure F-2 Example of a layered device Figure F·1 Relationship between a end driver structure user, a subsystem and the NT 110 manager. A subsystem and its native applications or subsystem-specific drivers can access an NT driver's device or a file on a mass-storage device only through file object handles supplied by the NT 110 manager. The 110 manager maintains for every device driver memory blocks, containing the following objects: • the device object • the driver-defined Device Extension The device extension is the most important data structure associated with a device object. lts internal structure is driver-defined, used to maintain device state information, to provide storage for any Kernel-defined objects or other system resources, such as spin locks, the driver uses, and to hold any data the driver must have resident and in system space to carry out its 110 operations. The memory for the device extension is allocated in de DriverEntry routine, when a device is created. page 118 J.H.M. Lemmers Appendices An NT driver has a set of system-defined (or standard) routines that lowest-Ievel and higher level drivers can or must have. When such standard function is called, an IRP is passed, together with a pointer to the target device object for the 1/0 request. The functions used by the AdDa device driver are: • Driver entry Is called by the 1/0 Manager and instalIs and initiates the device driver. • IRP_MLCREATE Is called after a FileOpenO-command. • IRP_MJ_CLOSE Is called after a FileCloseO-command. • IRP_MJ_READ performs the read operations • IRP_MJ_WRITE performs the write operations • IRP_MJ_DEVICE_CONTROL performs the 1/0 control operations, to configure the device driver • InterruptService routine Is called when an interrupt is generated by the device. The ISR running at a high IRQ level is able to interrupt the other device functions. The ISR must be as short as possible, to guarantee a maximum response. Less import actions must be performed by the DPC. • DpcForlsr The DPC is an extension of the ISR, running at a lower IRQ level. • DDStartlo A device driver must be able to queue read, write and other operations, because it must handle them one by one. If the device driver has finished an 1/0 request, the next 1/0 request is automatically taken from the queue and the 'DDStartlo' function is started to initiate the processing of this request. • DDStartUnload This function is called, when the device driver is removed. When a driver is loaded, its DriverEntry routine is calied with a pointer to the driver object. The DriverEntry routine sets one or more dispatch entry points in the input driver object so that the 1/0 Manager can route IRPs to the appropriate driver suppJied dispatch routine. The DriverEntry routine also sets the drivers Startlo and Unload entry points, if any, in the driver object and instalIs the Interrupt Service Routine (ISR) and the Deferred Procedure Call (DPC). A DriverEntry or optional Reinitialise routine also can use a field in the driver object to get information from and/or set information in the NT Configuration Manager's registry database An example of such information is standard configuration, like baud-rate and claims on re sources like interrupts. Every 1/0 request is represented by an IRP. An IRP is passed to function when it is called by the 1/0 manager. The IRP contains all the information about the requests. A device driver function has two possibilities to handle an IRP. It can complete immediate this IRP or it can queue the IRP, when it is not able to finished it at once. The 1/0 manager offers a device driver a queue to store pending IRP's. When an IRP is finished, because t~e request is satisfied, automatically the next IRP is retrieved from the queue and the DDStartlo is called, to start the handling of the next request. A device driver function is not preemptable, only by an interrupt. So a device driver must be constructed in a way; correct working is also guaranteed if it is a function in interrupted. Windows NT offers special construction to establish correct working. page 119 Appendices J.H.M. Lemmers references: [G-1] Windows NT Device Driver Kit (DOK) ; The Kemel-mode Guide (chapter 1 to chapter 16 ) The DOK containing a compiler, examples device driver, which are very useful and Iiterature about writing device driver. [ G-2] The Iittle device driver writer Ruediger R. Asche Software Development Kit (SOK) January 1996 ; technical artieles page 120 J.H.M. Lemmers Appendices Appendix H Measurements data Response f=170Hz f=3KHz Latency No load LOQload Heavvload No load Heavvload fus1 Counts Cum% Counts Cum'Y. Counts Cum% Counts Cum% Counts Cum% 10.0-11.0 0 - 21 0.042 0 - 0 - 5 0.05 11.0-12.0 0 - 23 0.088 0 - 2 0.02 124 0.129 12.0-13.0 14474 28.948 6 0.10 1 0.02 7 0.09 800 0.929 13.0-14.0 26405 81.758 20 0.140 419 0.840 882 0.891 5502 6.431 14.0-15.0 8764 99.286 144 0.428 961 2.762 85444 86.335 27150 33.581 15.0-16.0 266 99.818 14647 29.722 1051 4.864 13450 99.785 41224 74.805 16.0-17.0 10 99.838 20628 70.978 1525 7.914 19 99.804 18745 93.550 17.0-18.0 0 99.838 13767 98.512 1888 11.690 5 99.809 4918 98.468 . 18.0-19.0 1 99.840 368 99.248 3940 19.570 4 99.813 923 99.391 19.0-20.0 2 99.844 133 99.514 8931 37.432 1 99.814 130 99.521 20.0-21.0 4 99.852 97 99.708 11990 61.412 12 99.826 35 99.556 21.0-22.0 24 99.900 7 99.722 11192 83.796 4 99.830 47 99.603 22.0-23.0 28 99.956 3 99.728 5757 95.310 59 99.889 41 99.644 23.0-24.0 6 99.968 1 99.730 1620 98.550 63 99.952 40 99.684 24.0-25.0 6 99.980 6 99.742 270 99.090 19 99.971 40 99.724 25.0-26.0 4 99.988 5 99.752 64 99.218 13 99.984 45 99.769 26.0-27.0 5 99.998 16 99.784 27 99.272 10 99.994 57 99.826 27.0-28.0 1 100.000 25 99.834 20 99.312 2 99.996 39 99.865 28.0-29.0 22 99.878 18 99.348 4 100.000 43 99.908 29.0-30.0 18 99.914 16 99.380 30 99.938 30.0-31.0 16 99.946 18 99.416 16 99.954 31.0-32.0 8 99.962 9 99.434 14 99.968 32.0-33.0 7 99.976 11 99.456 5 99.973 32.0-33.0 6 99.988 19 99.494 11 99.984 33.0-34.0 4 99.996 22 99.538 9 99.993 34.0-35.0 1 99.998 22 99.582 4 99.997 35.0-36.0 0 99.998 25 99.632 2 99.999 36.0-37.0 0 99.998 19 99.670 0 99.999 37.0-38.0 o ~ 99.998 28 99.726 1 100.000 38.0-39.0 0 99.998 32 99.790 39.0-40.0 0 99.998 18 99.826 40.0-41.0 0 99.998 14 99.854 41.0-42.0 0 99.998 7 99.868 42.0-43.0 0 99.998 11 99.890 43.0-44.0 0 99.998 5 99.900 44.0-45.0 0 99.998 9 99.918 45.0-46.0 0 99.998 5 99.928 46.0-47.0 0 99.998 4 99.936 47.0-48.0 0 99.998 1 99.938 48.0-49.0 0 99.998 5 99.948 50.0-51.0 0 99.998 3 99.954 51.0-52.0 0 99.998 2 99.958 52.0-53.0 0 99.998 8 99.974 53.0-54.0 0 99.998 2 99.978 54.0-55.0 0 99.998 3 99.984 55.0-56.0 °1 100.000 3 99.990 56.0-57.0 1 99.992 57.0-58.0 1 99.994 58.0-59.0 2 99.998 59.0-60.0 0 99.998 60.0-61.0 0 99.998 61.0-62.0 0 99.998 62.0-63.0 0 99.998 63.0-64.0 0 99.998 64.0-65.0 0 99.998 65.0-66.0 0 99.998 66.0-67.0 0 99.998 67.0-68.0 0 99.998 68.0-69.0 0 99.998 69.0-70.0 1 100.000 Total 50000 50,000 50000 100,000 100,000 page 121 "'C '> J:Il "'0 (Q "'0 Cl) CD ...... :J f\) Q. f\) O· CD UI _af_ N"'-afcounla N...-af_ . :'l '" o :'l Ij 8 8 § ~ ~ 8 8 8 8 8 ~ ~ ~ § 0 0 0 0 0 0 0 § 0 0 ~ o § ~---~ II I I f I I I f 10.0-11.0 '00-11.0 l~ 10.0·11.0 ~ I I I I I I 23 I ,, 12.0-'3.0 • I I I I I I 12.0-'30 6 I 12.0-13.0 I I I I I I I I i·m; ; 26405 I I I I I , 14.0-15.0 ~4 I I 14,().lS.0 r : .~:; _ I 1 I I I J I 1.647 I I I I I I I " 11.0-17.0 16.0-17.0 16.0-17.0 10""" I I I I I I I 20628 , I 13t61 0 I I I I I I 18.0-18.0 ,mo 18.0·19.0 368 18.0-18.0 I , I I • I &D31 I I '33 2 J 20.0-21.0 lIm 20.0-210 97 20.0·21.0 11111,2 7 •2. 22.0-23.0 ~757 I I 22,1).23.0 3 22.0-23.0 2B I J I 1 6 240-25.0 '70 I I 24G-25.0 6 2•.0-25.0 8 64 I I 5 • 28.0·27.0 27 I I 28.0-27.0 16 28.0-27.0 5 20 I , '5 1 28.0-21,0 18 I , 28,0·290 22 28.0-26.0 0 16 I 18 0 300·31.0 '8 I 300·31.0 16 30.0-31.0 0 9 I 8 0 320-33.0 11 I 32.0-33.0 7 32.0-33.0 0 18 i1'". 6 -". 0 340-35.0 22 ~ : 34.0·35.0 ~ : 3oU~·35.0 0 i1': 22 •, 0 :D ~ '8 :D ~'g 111 ~i i 36.0-37.0 25 l' ::Il I 36.0-37.0 0 .. i I 36.0·31.0 0 :Z:::Il 18 I 0 . 1 0 :z:-)~ 1': l! 36.0-38.0 26 : 38.0·390 0 l> I;' I 360-380 0 fl;' 32 ~ -I 0 D- O E .0.~1.0 Ö ~ i 40_0~',O 0 i5' ~ i .0.0-41.0 0 '8 1 n • I. 0 l:..., ! 0 I I! .2.~30 1 :t.., ! .20"30 0 ~ .2D-43.0 0 J I 11 'ë 0 'ë 0 I . i .!. 44.0·45.0 .!. 44.O-CS.O - 44.0...5.0 5 I 0 0 8 J 0 0 4a_~70 0 48.G-47.0 • f , 4S.D-47.0 0 I 0 0 • 4ll.~8.0 .8.0-48.0 1 I .B.0-490 0 0 5 , I 0 0 50.0-51.0 3 I I 50.0-51.0 0 50.0-51.0 0 2 I I 0 0 52.0-53.0 B I 52.0-53.0 0 52.0·53.0 0 2 0 0 54.0-55.0 3 , 54.0·550 0 54.0-55.0 0 3 I 0 56.0-57.0 f 56.0-51.0 0 56.0-57.0 0 ,• 0 0 SB.0·58.0 2 560·590 0 56.0·59.0 0 0 , 0 0 &O.~1.0 0 I &0.0-61.0 0 &0 0·61.0 0 0 I 0 0 62.~.0 0 I 62.0-63 0 0 82.~.0 0 , I 0 0 0 I I 64.~5.0 0 64.0-650 0 64.0-65.0 0 I I 0 0 0 I I 66.~7.0 0 66.0-67.0 0 68.0-61.0 0 I ~ I 0 0 0 I , 680-69.0 0 68.0~9,O 0 ::r: 6B.0-68.0 0 I I • 0 0 ~ r; 3 3 Cl) ëiJ ~ :I: ~ ~ 3 3 (1) ën N...-oI_Io N_oI_ ~ ti' a UI ~ ~ ~ ~ t; ~ 0 1!I ~ l!: l!l ~ :ol 88 g 8 88888 8 § 8 8 8 § § § 0000000000 00 I o 0 0 I I I , , 10.0.'1.0 10.0·' 1.0 ~ IIIIIIII 2 I 12.G-13.0 IIIIIIII 12.G-13.0 7 I 5SQ21 IIIIIII 882 I es.l•• 14.0,'50 }==t=;==t=~~~~::2~11~~::'_~'__~'~ ••22;I 1•.0.15.0 '34sjl 11.0-17.0 , US ,e.o.'T.D '8 I 5 ,a.O-'QO 5123 :: : ".G-1DD 4 130 II I 1 20.0-21.0 3S I , 20.0-21.0 12 47 1 ot 22.0·23.0 •• I 22.0·230 5D 40 I 53 24.0-25.0 40 I 2".0-25.0 '8 45 I 13 2tl.o-27,Q 57 1 26.0-27.0 10 ~ 2 2B.0·2D.0 .J 2S.0·2U • JO 0 3O.0·J'.0 16 3Q.o.Jt.O 0 1. 0 32.0·JJ 0 5 32.0.33.0 0 II ... :D 0 :D 34.0.35.0 g I ~ : 34.0-35.0 0 :!:: :IJ' I :z:'g :IJ 0 ~'g I 36.0·J70 2 I l' ïl I 3&.0-37.0 0 1'ïl 11 0 I I :z: .. ] 0 z" ~I J80·3DO • I ':.. J8.o.JD.O 0 or; o I ~!_ 0 i 40.0-41.0 0 I Ö ~ a 40.0"",0 0 fi • 0 I ll.~ • 0 ...... " ! "2,0.430 0 I I ! 42.0-43.0 0 ê 0 I I I i 0 .!. ....0-45.0 0 I I I - .....0...5.0 0 o I I 0 46.0-47.0 0 :: 46.().. tps No load Logload Heavey load Logload Heaveyload [~s] Countedl Cum% Countedl Cum% Countedl Cum% Countedl Cum% Countedl Cum% 7.0-8.0 1 0.001 18 0.Q18 8.0-9.0 847 0.848 9498 9.516 9.0-10.0 83264 84.112 39145 48.661 10.0-11.0 23623 47.246 7 0.014 335 0.670 15729 99.841 35557 84.218 11.0-12.0 22859 92.964 99 0.212 785 2.240 25 99.866 12388 96.606 12.0-13.0 3388 99.740 1087 2.386 998 4.236 6 99.872 2817 99.423 13.0-14.0 60 99.860 6816 16.018 160 7.436 1 99.873 318 99.741 15.0-16.0 1 99.862 15886 47.790 7nO 22.976 8 99.881 26 99.767 16.0-17.0 1 99.864 16876 81.542 14797 52.570 15 99.896 20 99.787 17.0-18.0 2 99.868 5091 91.724 13661 79.892 43 99.939 27 99.814 18.0-19.0 6 99.880 2261 96.246 7338 94.568 22 99.961 11 99.825 19.0-20.0 4 99.888 1464 99.174 1986 98.540 15 99.976 27 99.852 20.0-21.0 20 99.928 288 99.750 471 99.482 15 99.991 28 99.880 21.0-22.0 14 99.956 10 99.nO 72 99.626 4 99.995 20 99.900 22.0-23.0 6 99.968 0 99.nO 23 99.672 3 99.998 24 99.924 23.0-24.0 5 99.978 2 99.n4 15 99.702 2 100.000 25 99.949 24.0-25.0 6 99.990 1 99.n6 13 99.728 15 99.964 25.0-26.0 4 99.998 3 99.782 8 99.744 10 99.974 26.0-27.0 1 100.000 2 99.786 10 99.764 9 99.983 27.0-28.0 8 99.802 17 99.798 8 99.991 28.0-29.0 10 99.822 12 99.822 3 99.994 29.0-30.0 9 99.840 9 99.840 2 99.996 30.0-31.0 11 99.862 12 99.864 2 99.998 31.0-32.0 19 99.900 15 99.894 2 100.000 32.0-33.0 12 99.924 5 99.904 32.0-33.0 7 99.938 10 99.924 33.0-34.0 15 99.968 8 99.940 34.0-35.0 6 99.980 2 99.944 35.0-36.0 2 99.984 8 99.960 36.0-37.0 4 99.992 7 99.974 37.0-38.0 2 99.996 6 99.986 38.0-39.0 1 99.998 2 99.990 39.0-40.0 0 99.998 1 99.992 40.0-41.0 1 100.000 3 99.998 41.0-42.0 0 99.998 42.0-43.0 0 99.998 43.0-44.0 1 100.000 tatal 50,000 50,000 50,000 50,000 50,000 page 124 Number ol counta Number ol count. 0> CD N ;: ë;; 0> CD o ou CD 0 0 .o o o o o 0• 0 g 0 '"o g '"o o '" 0 g g 0 o o o o o o o o 0 g g 0 0 ~ 0 o o o o o o o o o o 10.0-11.0 10.0-11.0 1335 I I I I I I I 10.0·11.0 0 II I I I I II II I I I III I I I I I I 11.0-12.0 11.0-12.0 .78S: II I I I I 11.0-12.0 7 I I , I I III II , I II I I I I I I I I 12.0-13.0 12.0-13.0 .99Q I I I I I I 12.0-13.0 99 II , I II I I I , I I I I I II I I I I 13.0-14.0 I 13.0-14.0 .'0~7 , I I II I , 13.0-14.0 _\600 I I I I I , I I I I I I I I I II I I 14.0-15.0 14.0-15.0 7170 , , 14.Q.15.0 681p , , I , , , , , I , I I I I 15.0-16.0 15.0-18.0 147$7 15.0-16.0 , 15886 I ,, , I 18.0-17.0 16.0-17.0 13661 16.0-17.0 1611 78 I I , I I , I 17.0-18.0 17.0-18.0 7:)38 I 17.0-18.0 50fll , , I I I I II 18.0-19.0 18.0-19.0 ....1986 I 18.0-19.0 ""'2261: III I I I I I 19.0-20.0 19.0-20.0 1471 19.0-20.0 _'~64 I I I I , I I , 20.0-21.0 20.0-21.0 72 20.0-21.0 288 I I I , I I , I 21.0-22.0 21.0-22.0 23 21.0·22.0 10 I I , , I I , I 22.0-23.0 22.0-23.0 15 22.0·23.0 0 I ,I I, I ! I I ii 23.0-24.0 23.0-24.0 13 ..., 23.0-24.0 2 I II ....., 0 , , I 0 24.0-25.0 :J: I 24.0-25.0 8 I 24.0-25.0 1 I I :J: •.. -4 I I , I !"-4 250-26.0 25.0-26.0 10 I :r '0 25.0-26.0 3 I II I ,..'0 : ~ , I , I I o • -4 28.0-27.0 17 ~ .-:: 26.0-27.0 2 I I II ca ... 'i 26.0-27.0 I III 0' :. 27.0-28.0 ~ 27.0-26.0 12 0' ~ 27.0-28.0 8 , II III :; III I I , a. - 28.0-29.0 28.0-29.0 9 a. 28.0·29.0 10 , I , I , I 29.0-30.0 29.0-30.0 12 29.0'30.0 9 I , , , I 30.0-31.0 30.0-31.0 15 30.0·31.0 11 I I I I , 31.0-32.0 31.0'32.0 19 I I 31.0-32.0 5 32.0-33.0 I I I 32.0-33.0 10 32.0-33.0 12 I I , I 32.0-33.0 33.0-34.0 7 I , 33.0-34.0 8 33.0-34.0 I I 34.0-35.0 2 34.o-3S.0 IS I I 34.o-3S.0 I I 35.0-35.0 8 35.0-36.0 8 I I 35.0-36.0 I I 36.Q.37.0 7 36.0-37.0 2 , I 36.0-37.0 I I 37.o-3Il.0 6 37.0·38.0 4 I I 37.0-38.0 , I 38.0-38.0 2 I 38.0·39.0 2 I I 38.0-39.0 I I I 39.D-40.0 1 I 39.0-40.0 1 I I , I 39.0-40.0 I , I ,, 40.0-41.0 3 I 40.0-41.0 0 I , I I 40.0-41.0 I I I , I 41.0-42.0 0 I 41.0-42.0 1 , I I I 41.0-42.0 I , I II "t:l 42.0-43.0 0 I 42.0-43.0 0 ,, , I 42.0-43.0 ll) I II I I <0 43.0-44.0 I I 43.0·44.0 0 , I , I 43.D-44.0 Cl) ...... I\) Ol "0 » Ol 'tJ IQ "tJ Cl) Cl) ..... :::J I\J Q. 0) g" en ... Nl.Imbef or counta ... ;; '"0 0 .0 '"0 ..0 0 ..0 '"0 ~ g g 8 ~ 8 8 8 8 ~ m ~ 0 0 0 0 0 0 0 I I ,, I , r r I 7.llO-8.oo I I I I I I 8.00-8.00 t847 I I I I '45 8.00-'0.00 832611 t--;...;_lil;--;-,.;--i--;-35-557 t I '0.00-11.00 1 15129 I I I I I 11.00-'2.00 25 I I I I 12.00-13.00 I 1 '3.00-14.00 ,. 00-'5.00 8 '5.00-16.00 15 g 16.00-17.00 43 g :00: ~ 17.00-18.00 22 .iL04 z.... li ;: 18.00-19.00 15 o ~ . Ö •~ ~ ! 19.00-20.00 115 20.00-21.00 21.00-22.00 22.00-23.00 2300-24.00 to 24.00-25.00 25.00-26.00 10 26.00-27.00 27.00-28.00 ~ 28.00-29.00 :I: ~ 2900-30.00 ~ 30.00-31.00 to 3 3 CO êil J.H.M. Lemmers Appendices T.o f=170Hz f=3KHz rusl No load Logload Heavyload No load Heavyload 7.50-8.25 1 8.25-9.00 201 14 7464 9.00-9.75 1 1620 30066 50833 9.75-10.50 19706 153 2159 64159 36386 10.50-11.25 27889 240 3886 5675 4551 11.25-12.00 2351 9523 10122 0 481 12.00-12.75 1 29609 19164 0 55 12.75-13.50 0 9762 9981 0 2 13.50-14.25 0 629 2150 0 0 14.25-15.00 0 0 0 0 0 15.00-15.75 0 17 509 1 2 15.75-16.50 0 0 78 1 0 16.50-17.25 0 0 23 1 0 17.25-18.00 0 0 1 13 0 18.00-18.75 14 0 1 32 5 18.75-19.50 22 0 0 12 13 19.50-20.25 4 2 0 11 14 20.25-21.00 5 0 0 9 12 21.00-21.75 0 0 0 0 0 21.75-22.50 6 0 1 4 12 22.50-23.25 1 0 2 2 15 23.25-24.00 1 0 2 0 6 24.00-24.75 0 2 10 24.75-25.50 6 1 15 25.50-26.25 13 4 17 26.25-27.00 15 4 10 27.00-27.75 11 3 14 27.75-28.50 7 2 7 28.50-29.25 0 0 0 29.25-30.00 6 10 12 30.00-30.75 3 10 3 30.75-31.50 2 3 2 31.50-32.25 0 8 4 32.25-33.00 1 8 7 33.00-33.75 7 8 33.75-34.50 6 2 34.50-35.25 5 7 35.25-36.00 0 0 36.00-36.75 2 6 36.75-37.50 0 8 37.50-38.25 0 4 38.25-39.00 1 4 39.00-39.75 0 6 39.75-40.50 1 2 40.50-41.25 1 41.25-42.00 0 42.00-42.75 1 42.75-43.50 0 43.50-44.25 2 44.25-45.00 0 45.00-45.75 4 45.75-46.50 6 46.50-47.25 3 47.25-48.00 2 48.00-48.75 2 48.75-49.50 1 49.50-50.25 0 50.25-51.00 1 total 50,000 50,000 50,000 100,000 100,000 page 127 "C l» 'tJ> (Q 'lJ (J) CD -... ::::J I\) Q. (X) Number ol counta Number of count. Number of count. n c.> .... CD '" '" '" en 0 ~ § ~ ~ ~ ~ ~ ~ ~ ~ 0 ~ ~ ~ ~ ~ ~ 0 ~ ~ ~ ~ ~ ~ ~ 8.25-9.00 8.25·9.00 7.50-825 I ,, I I • I I I • I 1 ,. IIII I I I I I 9.75-10.50 9.75·10.50 153 9.00-9.75 I I I I I I I I I "'5~ IIII I I ,.. I I I IDI22 ?S23 10.50-11.25 56- - 1125-12.00 I 1125·1200 I 1~164 j!IIiOO • 12.75-13.50 ., 12.75·13.50 762 12.00-12.75 • II 620 • 1425-15.00 I I 14.25·15.00 • 13.50-14.25 • I I 17 • 15.75-16.50 78 I I I 15.75-16.50 15.00-15.75 1 23 I I • 1 I I • 1725-18.00 1 1725-18.00 18.50-17.25 1 I I • 1 0 13 I I 18.75-19.50 , 18.75·19.50 0 1800-18.75 32 • I 12 0 I 2 11 2025·21.00 0 I I 2025·21.00 0 19.50-20.25 0 0 • 0 21.75-22.50 1 21.75-22.50 0 21.00-21.75 2 0 •2 23.25-24.00 2 23.25·24.00 0 22.50-23.25 0 2 0 24.00-24.75 0 I I I I I I I 24.75-25.50 1 ! 24.75·25.50 6 ..., ! 0 I I I I I I I 0 l3 ..., E • Z o 25.50-28.25 0 I I I I I I I ~ 2625-27.00 N 2625·27.00 15 , I I I I I • • -4 0 I 11 jL04 I I I I I , I z. r- • 27.00-27.75 0 F~ •2 7 I I I I I -4 27.75-28.50 I: 0 -4 27.75·28.50 o 0 -4 0 I I ZO 0 I 0 ca !l 28.50-29.25 I I I I I I I 0 I ~ 2925·3000 6 • I I I I I I I ! 2925-30.00 I. ! 0 I c 3 I I I I I I I ! I. • 2 ! 30.00-30.75 0 [ 30.75-31.50 I ...2 - 30.75·31.50 , ... • I 0 • I 31.50-32.25 3225-33.00 • 3225·33.00 1 • • 0 7 33.00-33.75 •0 0 33.75-34.50 33.75·34.50 0 • 0 5 34.50-35.25 0 35.25-38.00 0 35.25·3600 0 0 2 0 38.00-38.75 0 • 38.75-37.50 3875-37.50 0 0• 0 37.50-38.25 0 3825-39.00 1 3825·39.00 0 0 0 39.00-39.75 0 •, 39.75·40.50 0 39.75-40.50 I 0 1 0 40.50-41.25 0 4125-42.00 • 41.25·42.00 0 0 1 0 42.0Q-42.75 • 42.75-43.50 • 42.75·43.50 0 0 2 I 0 43.50-44.25 • 4425-45.00 0 I 44.25-45.00 0 • • I 0 45.0Q-45.75 0 45.75-48.50 • I 45.75·46.50 • 0 I 0 46.50-47.25 4725-48.00 ,• I I 4725·48.00 I • I I I • I • 2 0 48.0Q-48.75 0 I I I I , 0 0 48.75-49.50 I I I 48.75·49.50 I 0 0 0 I I I I 49.50·50.25 5025·51.00 1 I I I 5025-51.00 • I 0 I :cc.. ~ {; 3 3 (J) in c.... J: ~ Number ol counls Number ol counll {; '" '" c.> .. ... 3 ~ ~ 8 ~ ~ '"~ ~ ~ ~ ~ ~ ~ 3 0 8 0 i ~--~ m 7.50-825 • ül 7"" 9.00-9.75 " """"6 '~"'§ 50033 9 00-9 75 "'S~ ~ 10.50-11.25 507 1050-11 25 ,ss, : 0 I 12.00-12.75 0 48' I 0 12.00-12.75 S I 13.50-14.25 • t: I , 15.00-15.75 •, 13.50-14.25 , 16.50-17.25 , 13 15.00·15.75 18.00-18.75 32 16.50-17.25 19.50-20.25 11" • 6 0 21.00-21.75 18.00-'8.75 S ,• 13 22.50-23.25 • 19.50-20.25 0 , , " E 24.00-24.75 0 I I I I I " ~ I I I I I I I E 21.00-21.75 25.50-28.25 •0 I I I I I I I ~ • F I I I I I I I :J: I 1'-4 " i -; 2700-27.75 • I I I I I I .... 22.50-23.25 IS • I I I I I I I ~~ 0 .... I I I I I I I ! l!l 28.50-29.25 • l!l • I I I I I I I l5' 24.00-24.75 I. 'ë I I I I I I I ! .!!. 30.00-30.75 •0 •ca. IS f ca. 0 25.50·26.25 17 31.50-32.25 0 I. 0 33.00-33.75 0 27.00-27.75 " • 7 34.50-35.25 0 28.50-29.25 0 0 38.00-36.75 • " 30.00-30.75 3 37.50-38.25 •0 0 ,• 39.00-39.75 0 31.50·32.25 0 40.50-41.25 0 33.00·33.75 0 42.00-42.75 •0 34.50·35.25 43.50-44.25 0 0 3600·3675 l: 45.00-45.75 • 46.50-47.25 •0 37.50·38.25 0 48.00-48.75 0 39.00-39.75 16 • 49.50-50.25 •0 :r> "C "t:l "i lil :::J CO Co (l) n ...... CD I\) lI) CO Appendices J.H.M. Lemmers Appendix I List of used terms ADDA board/card a board, which is capable to convert signals from Analogue to Digital signals and from Digital to Analogue . API Application Programming Interface. The routines available for user applications to communicate with the operating system Booch object oriented software deve/opment methodology (see chapter 6) CASE-tooi Computer-Aided Software Engineering-tooi (see chapter 7) class a temp/ate, a description, a pattem of a 'blueprint' of a category or a collection of very similar items or objects. CoadIYourdon object oriented software development methodology (see chapter 6) context switch the procedure of saving the volatile machine state associated with a running thread, loading another thread's volatiIe state, and starting with the new thread's execution core see kemel DOK Device Driver Kit, Microsoft's developinent tooi for developing device drivers DPC Deferred Procedure Call. A DPC is an extension to an ISR, but is running at a lower priority DSP Digital Signal Processor, specialised in processing data signals embedded system a computer system, which is a part of a bigger system and which plays a role essential to the continuous functioning of the bigger system. GUl Graphical User Interface hard reaf-time hard real-time systems have time-constraints, that always must be met, otherwise the system fails interrupt latency the time the computer system needs to start the interrupt service routine, after an interrupt is generated. interrupt service routine the routine, containing the code the handle an interrupt. The interrupt service routine is called, when an interrupt is detected. ISR Interrupt Service Routine kernel the most important and intensively used part of the operating system. The kemel is the hart of the operating system and is responsible for process and thread administration, dispatching and scheduling, interrupt processing and hardware interfacing. LPC Local Procedure Call. A Windows Nrs facility, providing fast and efficient message-passing between processes. MC Application the Measurement and Control application (see chapter 9) MFC Microsoft Foundation Class. This library all kind of standard C++ objects, Iike windows, brushes and arrays to speed up the deve lopment of Windows NT/95/3.1 applications micro kemel a smal! fast kernel, usually highly specialised to an application. To achieve speed and predictability, the kemel is stripped down and optimised MSC notation technique used to record scenarios. MSC is used in com bination with SOL (see chapter 6) non-preemptive scheduling a scheduling technique, where resources can only be given back to the operating system by a resource-user nucleus see kemel object a model, an abstract description of a real word entity, only including the relevant information. OMT object oriented software development methodology (see chapter 6) preemptive scheduling a scheduling technique, where resources can be taken from a process by the operating system priority inversion means that a high priority process is prevented from execution by a lower-priority process for an indefinite period of time process or a task is a stream of instructions, an independent piece of program in execution real-time a real-time system has to satisfy time-constraints. The system has to respond predictab/e and within time-constraints to external events. page 130 J.H.M. Lemmers Appendices resource a resource can be a hardware device or a piece of information. Pro cesses needs resources to execute. response latency the time the system needs to respond to an extemal event . ROOM object oriented software development methodology (see chapter 6) RPC Remote Procedure Call. An industry-standard communication facility for client and server processes across a network RTOS Real-Time Operating System Rumbaugh see OMT SAiSD functional oriented software development methodology (see chapter 6) SOK Software Oevelopment Kit. This kit is a Iibrary of articles, manual and examples to develop software for all kinds of Microsoft products. This library is places on CD's SOL functional oriented software development methodology (see chapter 6) Shlaer/Mellor object oriented software development methodology (see chapter 6) soft real-time a soft real-time system requires the ability to meet deadlines, how ever failure to do so does not means the system failed. State transition diagram technique to describe the behaviour of a system in terms of a finite number of discrete states, conditions for a state-step and actions related to a state thread thread is a Iightweight process, without his own address-space TUE Eindhoven University of Technology validation checking if the system meets its requirements (are we building the system right) verification checking ·if the system meets the user's requirements (are we building the right system) Visual C++ Microsoft's software development tooi to develop software for Windows NT, Windows 95 and other platforms Ward/Mellor see SAiSO page 131