Section #1 – Real-time system
The main focus in a real-time system is reactivity – don’t include an operation that will take too many CPU cycles to complete in case an interrupt request comes in that will need to be processed immediately. For clarity, my assumption of the overall operation of this real-time system will be to monitor such things as heart rate, blood pressure, breathing rate, and (maybe) brain activity in order to deliver a drug that keeps the patient unconscious, without administering too much (or too little) medicine.

Arrays – Arrays will be necessary in order to monitor a particular drug’s ‘history’ during the running time or the particular medical procedure. Each medicine could have its own array with indexes possible marking the elapsed time (in milliseconds). In order to avoid memory allocation delays it is necessary to have arrays statically bound before run time. This may result in wasted space, but would ensure fast access to array elements. Operations on the array will only include primitive data operations on individual elements of the array. Matrix operations such as reversing, inversion, and dot products will not be allowed.

Multidimensional arrays – Because multidimensional arrays can be implemented as an ‘array of arrays’, it would be relatively simple to implement as long as the number of dimensions does not get too large. This would risk having the systems spend too much time calculating the address of the memory location of the element. Again, no matrix operations will be allowed.

Records – Although there may not be a need for record types other than for readability, record types are similar to arrays in form. They will be allowed because the structures are created at compile-time. Their access time can be fast and consistent.

Lists – Most of the data in this real-time system will be kept in a linear fashion with the beginning of the medical procedure being t₀ and array indices increasing from 0 at that point. This means that any list of values will be kept in an array rather than any linked structure (see pointers below). Since most of the data activity will be writes into the next larger index of an array, performance will be very good for writes. Any concern over searches can be overcome with the constant calculation of running averages and point in time max/min updates. Also, many searches will return ‘the last time some event occurred’ (such as ‘How long ago was drug X administered?’). This means that the searches will begin at the end and move toward the beginning of the array and will find the value needed before the reaching the mean of the array index.

Character Strings – Strings should be dealt with as arrays if implemented at all. The real-time would seem to work faster on primitive data types (assuming that char strings are not primitive). Also, the user interface would be designed to accept and present only Boolean (on/off toggles) and numeric (LEDs) values. Any analysis would be done by an external CPU or process that could massage the raw data and present a more readable format to the doctor.

Pointers – Absolutely not. The danger of memory leaks from programming dangling pointers would risk crashing (or seriously degrading) the system. Or, the need to include an O/S garbage collection might jeopardize the real-time reactivity.

Sets – Although sets do not seem to degrade the real-time functionality, many implementations of sets can be satisfied using arrays. If already included in a language, sets would not disqualify it from being the best choice. However, if a language were being designed for this system, sets would be a low priority to include in the functionality.

Section #2 – Event-driven elevator control
This system would seem to have two components. This first is the mechanical control of each individual elevator and the second is an overall system that manages all of the elevators in the most efficient way possible (i.e. – make sure all the elevators aren’t at the top floor at the same time).

The first component has the most ‘life and death’ implications, but is also the simpler of the two systems. It would really only need to ‘know’ what floor to which it was going and to monitor the emergency braking system in case of a malfunction. All other details such as which floor it was on, setting the motor to the proper direction, opening and closing the doors are done with electromechanical switches. The matter of the emergency brakes would require some sort of real-time sensing and interrupt, but could happen on the order of seconds – specifically, 3 seconds or less – to avoid harm to the passengers. That all being said, many of the suggested data structures would not be necessary. Arrays might be useful in organizing the data and keeping a small history, but multidimensional arrays may require more memory than is in the system. Character strings might be useful in reporting to the controlling system, but could be just as easily implemented with character arrays. This component would run very well with primitive data types.

The second component is, of course, less critical in terms of bodily injury, but a failure in this component would be very annoying. Its primary function would be to optimize workflow of the set of elevators, but could also keep a history of utilization and maintenance. This process could be run on any general purpose operating system and programming language. All of these data structures would be useful to the readability and writability of the code, but some are more necessary than others.

Arrays and multidimensional arrays – Because of workflow analysis, arrays – including multidimensional arrays – will be necessary. The physical computing system should have enough memory to handle these structures.

Records – Records will be used to organize the instances of each elevator that the system manages. Elements such as ‘floor’, ‘destination’, ‘next_destination’, etc. could be kept in this record.

Lists – Lists would be required to hold the order of ‘calls’ assigned to each elevator. As a person calls any elevator to their floor, this system would decide which elevator is ‘best’ to service the call and place that call in the elevator’s queue (linked list).

Character strings – This data structure would be necessary for reporting to a maintenance person (or maybe a police investigator). Printed output could be used for history and analysis.

Pointers – Because of the use of linked lists (queues), we will need pointers. We will not know the length of the queue in advance. So, dynamic memory will be necessary.

Sets – Sets could be a useful tool for organizing the bank of elevators that are managed, but not necessary since this could be implemented as an array. Take it or leave it…

Section #3 – Payroll system
A payroll system is more complicated than the examples above simply by the amount of information that it must process and the complicated (and changing) rules that it must be allowed to follow. The short answer is that all of these data type are necessary for the writability, readability, and maintainability of the code. Now, the explanations why…

Arrays and multidimensional arrays – Since most of the employee records in a payroll systems will need to be operated on, it will be necessary to allow all or part of them to be moved into memory at one time. This will make linear movement through the entire array very quick (as compared to disk access of each employee record). Multidimensional arrays will be useful in operating on a particular field of a record (i.e. – summation of total payroll tax owed).

Records – These are very necessary for organization of each employee record. Otherwise, the writer would have a lot of correlated arrays to manage each element of information. Records will make the program more readable and maintainable.

Lists – Because there will be instances of queues (or trees) which the size will not be known ahead of run-time. Linked lists will be necessary. An example might be to keep a list of corporate matching to a charity – not all employees would participate in this program.

Character strings – Strings would be necessary for input, comparison, and output. Although character arrays may satisfy this need. Strings as a more native type to the language may be a better choice for writability.

Pointers – Because of the need for linked lists, pointers will be necessary. The programmers must understand the language enough to incorporate manual garbage collection if necessary.

Sets – Sets will be very useful – even if incorporated as an enumerated data type. The readability of set operations (i.e. - if VAL in SET_A) can make the code more readable and maintainable. If this is a concern in the development cycle of code, it should be included.