EEE3074W: Embedded Systems

The Project

E.B.E.

START

Introduction

Details

Labs and Project

Outcomes and Syllabus

Scope: This page tells you about the subsystem prototype project done in EEE3074W.

In EEE3074W, students work on just one project. But, the project runs for almost the entire length of the course, and is done in parallel with lectures and laboratory practicals. The project is divided into four main parts, each of which involve milestones that must be delivered by a specific date. The following sections describe each part of the project. The last section (Other Aspects) provides additional detail about project-wide issues.

Part A: Conceptualization

The project starts by ideas of possible embedded system products being tossed around, bounced off the lecturers, discussed with fellow classmates and anyone else who gives one the time of day, and posted on the EEE3074W project concept forum on Connect. This "idea tossing" strategy forms the initial part of The Project.

The lecturers together review the list of suggested product concepts, divide the products into a set of N categories such as Security, Transport, etc. (where N is partly dependent on the class size). Then, a selection of the most interesting, and promising concepts are made, and based on this selection, and the N categories determined, students are divided into groups of 3 (and the occasional group of 4). After this, the groups are required to work the initial concepts into a more refine product concept, which involves developing a short description of the product concept, as well as a digital poster, and slide show (using PowerPoint or OpenOffice). Use-case modeling is encouraged.

Further detail for Part A:

Part B: Modeling and Experimentation

Once the concept presentation is complete, the teams need to develop a plan of action for which subsystem they want to prototype (as developing a complete system is likely to take too long). During this step, they develop high-level UML models using RT-UML.

The next milestone involves modeling. The models should focus only on the subsystem to prototype, showing important design decisions and considering its integration / interfacing aspects with the rest of the system.

Each member should be responsible for two models and they should be initialed by the author. The group is jointly responsible for use case diagrams and a circuit diagram, of which a sample can can be submitted in an entirely rough and ready form. The other diagrams should be done on computer.

You may want to start developing prototype code (see Part C), and an initial circuit diagram to help refine the models. Neither the circuit diagram, not any code will be marked for this milestone; however an initial circuit diagram needs to be submitted so that I can review it.

Modeling should not be done entirely in isolation; that is not the idea. The intent is that you should agree on functionality in the group, perhaps developing rough versions in the meeting; but the final, more refined version should be drawn up on computer individually; and will be marked separately from the group submission. Do not go into excessive depth in the modeling; time is very limited; you should rather focus on modeling important aspects of the subsystem, connections to the rest of the system, especially including refinements for developing the prototype. Timing and other important QoS requirements should be indicated in the relevant RT-UML diagrams. Class stereotypes (e.g. Entity, Control and Boundary) should be indicated. The models to submit are listed in Part B: Modeling Requirements.

Further detail for Part B:

Part C: Implementation

The main part of the project involves developing the subsystem prototype. Students may write code that runs directly on the hardware, and uses no operating system, or they can choose to use an embedded operating system and develop device driver(s) for it... generally, students choose not to use an operating system, and this is possibly an advantage at this level, so that they clearly understand hardware/software interfacing.

Further detail for Part C:

Part D: Factory Acceptance Test (FAT)

The final part of the project involves a simulated Factory Acceptance Test (or FAT), in which the students demonstrates the subsystem prototype, and performs tests to show that requirements are satisfied.

Further detail for Part D:

Other Aspects

This section includes items relating to the project as a whole, i.e. all parts.

Repository

All teams have a shared repository in the /REPOSITORY/Project/TEAMn directory, where n is the number of your team. You should keep the MASTER files for your project under the MASTER directory in your repository. Start by putting your initial version of the concept slides in directory MASTER/Concept.

Logs and Indication of Work

The project leader is required to keep logs of important decisions made by the team, and major tasks that team members have worked on (the project leader should include the activity of project management and log keeping as an one of these tasks). All team members are recommended to keep a log book of what they worked on and how long they worked for, so that they can demonstrate more conclusively what work they have done should a situation arise where this information is needed.

Navigation: [Start] [Next: Part A]