EEE3074W: Embedded Systems Part D: Demonstration / FAT

E.B.E.

Scope: This page tells you about Part D of the EEE3074W project.
 

Overview

An embedded engineer is engaged in communication at a variety of levels, and in different contexts. Part A involved the concept presentation, which was a context in which you communicated your knowledge and ideas at an inter-discipline level, using terminology suited to an audience not comprised of embedded systems experts. On the way to the Part-B submission, you collaborated with peers in an informal context where (I hope) the level of communication involved more specialized language, such as real-time system terminology and design drawings. The demonstration is yet another context, and really rivals the concept presentation in the difficulty involved in doing it properly...

The demonstration part of the project is intended to simulate a Factory Acceptance Test (FAT), which is a very formal affair that generally involves a thorough interrogation of the product installation before the client signs an agreement that states the system is working as desired (this may not necessarily involve meeting the original requirements 100%, but rather agreeing that the system is working sufficiently well for the required purpose). Often, the FAT is only performed and signed-off after a period of time (sometimes months) during which the installed system has been running satisfactorily. We will cut down on all this, and treat the subsystem as a mini system that is to be demonstrated and showed to be adhering to the requirements. Figure 1 shows the major aspects of the FAT.

Figure 1: UML diagram showing aspects of the FAT.

Sign-up Sheet

Use the Connect sign-up service as per the sign-up strategy used for lab pracs.

Realities of Prototyping and Implication on Marking

The ideal to strive for is a fully functional prototype, with all the bleeps and flashing LEDs. Being able to demonstrate what you've got is an acceptable comprises. The mark for the demo will be based on both the operational condition of the prototype, and the quality of the demonstration. If you have and have divided the work effectively, and have been working consistently, you should have no problem delivering doing demo.

Preparation and Planning

I haven't come across many professional engineers who are able to ad-lib an important demonstration. Although your team may be comprised of individuals who can do this, I would prefer that everyone is involved in planning the demonstration, and do a dry run beforehand.

Time Limit

Plan on 15 minutes, if not less. Unexpected delays tend to happen, and I will probably have questions to ask.

Presentation and Content

Important: Each team member must present something. It will reflect badly on the team as a whole if a team member is absent or not involved. One team member should not dominate the entire proceeding.

Suggested demonstrate plan:

• Start the demonstration by recapping what your project involved, and the reason for the particular choice in subsystem prototype.

• Briefly identify and explain each of the physical components involves, and how they are connected (this should include the host/PC)

• A prototype is really a form of experimentation: it is done to play around with ideas, and to test things out. So, explain your experiment: what is the particular prototype you have prepared going to show?

  • This often involves identifying tests and important parts of the code, and what it does.

• Perform the demonstration. It is up to you how you want to do this. You may want to show the procedure from compiling the code to running the code and showing test result.

  • If you have to make code modifications in order to demonstrate certain aspects, it is best to indicate what you are changing, and then do compilation and upload as needed.

  • If you have built in more testing/debugging functionality, and have the ability to access this functionality from some form of UI, then the compilation and upload stage is probably not necessary.

• Finally recount the results of the demonstration. Was the test successful, does the prototype operate as planned. Or did you discover difficulty in achieving the desired results?

I look forward to seeing your demonstrations!