EEET1262/EEET2166 Real Time Systems

Real-Time Systems – Design Project 2019

Overall assessment value is 40% for both EEET2166 and EEET1262

Aim: To work through the process of designing a real-time system and demonstrate an implementation. Complexity of design will achieve a higher grade only if implemented in a sensible and justifiable manner – Your claims will need to back-up by evidence during demonstration.

You are to design a Traffic Light control system according to the requirements given in this document (pages 2-3) and implement a "proof of concept" solution.

Project Overview

1. Form a group of three or four - Groups of four are expected to deliver 33% better solution/documentation. Marking schedule will be adjusted to group size.
2. Each group must develop an initial design for the Traffic Light control system and submit an initial design report (an outline of the expected report contents is given on page 4).
3. Develop a “proof-of-concept” implementation using the QNX Real-Time Operating System. Each group must demonstrate their solution in week 12. Demonstrations will be at a time scheduled by the lecturer at the end of the semester that does not clash with University or school commitments such as Design 3/4 presentations.
4. Submit the final report (the required contents of this report are given on page 5) and the final software.

Marks allocation

This project is worth 40% of the marks for the course. The marks allocation is broken down as follows (out of 100% for the project):

• Initial Design Report 5%
• Final Report 15%
• Implementation 20% (this includes the software demonstration)

Submission Requirements (due dates are given above)

Implementation

Implementation must be done using the QNX Real-Time operating system with software written in C or C++ and must use the QNX supported interprocess communications (IPC) and synchronisation primitives.

Traffic Light Controller

Use the real-time systems design methodologies outlined in lectures to develop and design a realtime system for traffic light control according to the specification that follow. You will be required to develop a functioning “proof-of-concept” implementation using QNX. Use Design Diagrams (including UML variants) to document your design.

Traffic Lights Control System Requirements

The system is to control at least two sets of traffic lights and a set of boom gates for a busy train line at intersections as given in the following diagram. This is the minimum level of complexity to achieve a Pass grade.

In the example above, there is a road (R3 going from top-left to bottom-right of diagram, but it actually goes in a North-South direction) along which there are two road intersections (I1 and I2) and a railway crossing (X1). The crossing roads at each intersection (R1 and R2) each go in an East-West direction. All roads (East-West and North-South) carry two-way traffic, have two lanes in each direction, may have turn lanes at each intersection (I1 and I2), and may have pedestrian crossing lights at each intersection (I1 and I2). R1 and R3 are major roads with a high levels of traffic, whereas R2 (whilst still a major road) has only a moderate level of traffic.

The railway crossing has boom gates and red flashing lights that operate whenever a train crosses the road. There are two train lines, one for trains travelling each direction. The time between trains varies from frequent (as little as 2 minutes apart) at peak hour to infrequent (about every 20 minutes) at night (~10pm) - All night trains run on Friday and Saturday nights. The traffic light system can sense the state of the railway crossing (but has no control over it). The train should receive a red light if there are any issues with the boom gates – thus indicating an error which should be reported to the control room.

Each intersection/pedestrian crossing has a local controller for the lights at the intersection which operate continuously (except for hardware failure). Each local controller also communicates with a central controller (but should continue to operate if either communication link fails).

The two intersection controllers (I1 and I2) operate independently, however can receive commands from a central controller to determine the light sequence pattern that they should follow for different times of the day. However both intersection must sense the state of the railway crossing (X1) and sequence their set of lights for R3 red when a train is crossing at X1, whist still trying to accommodate traffic on the all three roads. The support for pedestrian buttons and lights should also be considered.

There is a central control room with a central controller, which monitors the traffic lights and displays the status and light settings received from the individual intersections. Therefore, each local controller will send a status message to the central controller whenever any of the lights at that intersection change state, and act on any commands received from the central controller.

Note that the central controller does not directly control the individual lights at an intersection - that is always done by the local controller and must be maintained even in the event that the controller cannot communicate with another controller.

Modelling your design on a real life intersection:

Below is an example intersection in Melbourne which might help with breaking down the problem. You can base your design on a real life intersection if you like - this may help with you formulating your justifications and requirements. You can include tram line signalling if needed too.

By measuring the distance between the traffic light intersections and train crossing you can start to determine the timing requirements and traffic light sequences that will be needed in-order to clear the intersections and avoid traffic backing up. By making some realistic assumptions, the side roads can be eliminate from the design as they are not important. As an example, during peak time with trains approaching from both sides, it can take between 3 to 10 minutes to follow the path outlined by the red arrows if there are pedestrians trying to cross Glenroy Rd or Hartington St.

Image source: https://www.google.com.au/maps/@-37.705977,144.9167887,18z

Possible light sequence patterns for each intersection local controller (set by a command from the central controller) include:

• Fixed timing – commonly used during peak hours
• Sensor driven (react to local car sensors & any pedestrian buttons) – commonly used in off-peak times.

The central controller may send a command to change the sequence a few times a day (e.g. depending on the time of day).

Operators in the central control room will occasionally send commands to the intersections, boom gate control and train approach signals system.

The central control room may also initiate override commands that are sent to the individual intersections to deal with exceptional situations (e.g. to provide a clear path for a visiting dignitary).

At all times the lights at each intersection must exhibit the “expected” behaviour of real traffic lights, however the timing between state changes may be speed up for practical and demonstration reasons.

These specifications do not describe every possible feature of the intersections, leaving some room for variations in solutions (e.g. pedestrian lights, right turn arrows etc at the intersections).

You will need to simulate sensor events in your implementation e.g. using key presses (this will require an additional process or thread to wait for the key presses). You are free to use console input, the provided beagle bone keypads, or GPIO developed on your own DE10-nano or Beagle Bone targets.

To achieve a Credit to Distinction level you are expected to use the keypad and LCDs provided on the beagle bones, however custom hardware implementations will attract higher marks. Generally, console only based systems will only attract Pass level grade.

Note that a demonstration using only three QNX node will attract a Pass to Credit level (e.g. I1 running on one computer, I2 running on a second computer and a third computer acting as the central controller or train controller). It is expected that your solution will have three or more QNX nodes. Separate process on each node may handle the pedestrian/sensor inputs, with another process used to display the traffic light states.

You are not required to have a graphical user interface; it is sufficient to display the state of each intersection by writing simple text messages to a terminal window, the provided beagle bone LCDs or a customised hardware display on your own target/s. You are encouraged to use the provided Beagle Bone LEDs and LCD to display states or your own interface hardware. You can also make use of the persistent file system on each target under the /fs directory. You can store test vectors or debug information for offline analysis, or any other feature you think is suitable.

You are free to make any reasonable assumptions necessary to proceed with the design, however it is a good idea to justify your decision on a simplified real-life traffic light intersection.

As an example, a group aiming for High Distinction grade level would propose and deliver a system using 4+ ARM QNX nodes with custom hardware with IPC implemented with native message passing techniques and a host of features such as: updateable pattern sequencing; external sensors and displays; custom hardware; separate nodes for each intersection and controller; appropriate synchronization primitives; timers and software/hardware interrupts; excellent code management and commenting; and host of well thought-out features and well timed demonstration/presentation. Obviously, there is room for movement as a given team might focus more highly in certain features over other features or implementation methods.

Initial Design Report

Due date and assessment value information is given on Page 1 of this document.

The initial design report shows the steps you went through in the design process leading to your initial design. Expected design documentation includes:

• Your interpretation of the problem, and any assumptions you made about how the system will operate.
• A detailed diagram of the intersection layouts for your design indicating the various lights and sensors (which depend on the intersection features supported, such as right-turn arrows and pedestrian crossings).
• State Charts describing the lights behaviour at each intersection.
• Use Case diagram(s) and use case scenarios including relevant State Chart(s) and written specifications.
• Behavioural specifications such as sequence diagram(s) or collaboration diagrams may be included.
• High level implementation diagrams especially a task architecture diagram.
• Overview of messages sent between tasks (type, purpose and outline of message content).
• Add explanatory notes particularly to diagrams, to ensure that your design is fully documented and clearly explained.

Diagrams must be clearly labelled and numbered (this will help if you refer to any diagram in the initial report from the final report).

Report must have a Table of Contents, professional layout and proper page headers and footers. It should also include a contribution declaration from each team member and coverpage.

Software Demonstration (Implementation)

Each team will be required to formally demonstrate their solution. All team members are required to attend and present an aspect of the solution. Demonstrations will be scheduled by the lecturer in week 11 and be held in RMIT laboratory 10.09.11 on Friday in week 12.

To be eligible to attend the demonstrate session, all code and a copy of the final report must first be uploaded to Canvas prior to 9am Friday in week 12. You will be given no more than 10 minutes from the time of your appointment to setup and test your solution and a maximum of 10 minutes thereafter to present your working solution.

You will be assessed on your professionalism as well as your technical justifications and solution. Remember: An unjustifiable and overly complex system does not equal good marks. Equally an overly simple design will not achieve a good mark and may result in less than 50%. You are expected to demonstrate where you used any interprocess communications (IPC) and synchronisation primitives, as well as how you tested your solution.

Final Design Report

The due date and assessment value of the final design report is given on Page 1.

The report must follow the format given here, including detailing your final design, highlighting any changes from your initial design and discussing why the changes were made. The final report should bridge the logic gaps over the initial design report.

Note that for diagrams which are unchanged from the Initial Design Report there can be repeat in the Final Report - just make a reference to it. You will not lose marks if you make amendments to your initial design as long as they are justified, and the benefits are clearly explained. It is expected that there will be some changes implements between the initial design report and the final report.

In this report you must address the following points:

1. Restate the problem as you now understand it in your own words. State what assumptions you made and how you interpreted what you had to do. You should also state what constitutes a solution to the problem. Extract the design requirements and benefits of your team’s solution!
2. Provide a formal statement of your solution to the problem together with explanations, proofs and other evidence to justify your solution. This must include detailed design diagrams, message formats and message protocol descriptions. An evaluation of the solution should be given and, where appropriate, you should suggest how your results could be generalised and possible directions in which future work could proceed.
3. Report on the solution process that you went through to arrive at your result (from initial design through to final implementation). Describe your attempts to solve the problems. Show how you started off, how your understanding of the problem developed, what you tried at various stages and any important insights and breakthroughs which occurred as you sought solutions to problems that arose. You should highlight, with hindsight, the problem-solving strategies, any mathematical techniques, formal methods, testing methods, and computer assistance you tried. Any rough notes made in exploring the problem may be included as an appendix.
4. Discuss the safety and fault tolerance requirements for this system and what you would do to address these requirements in a real system. What happens if a node fails? You should include a comprehensive test plan.
5. Reflect on the project. Think about what you have learned by doing the project and reflect on the original objectives of the project compared with what you finally achieved. Suggestions for improvements that you feel will enhance the project for students studying this subject in the future will be greatly appreciated.
6. Give a brief acknowledgment of the ideas or other help provided by other students, specialist information sources, and so on. Include any references actually found to be useful in the solution of the problem.
7. Include any appendices that may help the reader understand important details of your report (e.g. extending test plans/scenarios). Appendices should only be included if they have been specifically referred to in the text. They should be numbered consecutively and each should bear a title.

The assessment breakdown for the above points in your report is: 10 + 30 + 20 + 15 + 15 + 5 + 5 = 100

Report must have a Table of Contents, professional layout and proper page headers and footers. It should also include a contribution declaration from each team member and coverpage.

Remember: A well-structured, short and concise report is better than a long winded document. Use your appendixes to make the main document easy to read. Significant diagrams should be within the main report and accompanying text. All diagrams should be referenced by the main text.