Assignment for Credit
Course Code : ENG 5220 Course Name : Real Time Embedded Programming
Type : Technical Report
Oral Presentatton &
Public relattons
Title of Assignment : Development, design, constructton and
promotton of a product requiring realttme operatton
% of ffnal course mark : 100% Lecturer : Bernd Porr & Chongfeng Wei
Marking
1. 10% will be awarded for the inittal pitch of the project (every team has 5 mins and two slides)
and inittal github pages up and running (special ttmeslot, see moodle). We assess here the
originality/usefulness of the work, if it has a solid realttme requirement and the quality of the
presentatton.
2. 25% of the credit for the ffnal submitted work will be based on the way the code is
structured, that it is divided up in classes allowing encapsulatton of data, using data
structures in a failsafe way, receiving data and releasing data in a safe way and in general
guaranteeing high reliability and ease of maintenance.
3. 30% of the credit for the ffnal submitted work will assess the realttme coding of the soffware
and how this has been achieved. This includes whether processing of events has been
achieved by waking up threads and in general employing event driven code using callbacks,
ttmers, signals, threads, and/or kernel space interrupt driven coding in preference to polling
or other less suitable methods.
4. 25% of the credit for the ffnal submitted work will be based on the use of revision control,
committtng, branching, creattng releases, testtng and project planning. Marks will be
awarded for demonstrattng clear division of labour and documentatton of the work. Has git
been used as a revision control system or just to ``upload'' code? Has git been used to do
revisions, track bugs and has there been a release strategy? Has the issue tracker system
been used? Have unit tests been used?
5. 10% of the marks are devoted to the promotton of the work: has the project been properly
presented on github so that it catches the eye of a potenttal user? Is the hard/soffware
described in a way that other people can reproduce it? Has the project been adverttsed on
social media and has it been picked up by online publicattons such as hackaday? Has a social
media account been created and has it created a buzz around it? Has the project a license?
All items above will marked on the 22 point scale, according to the performance indicators written
overleaf. Consideratton will be given to the inclusion of Aims and Objecttves and clarity of
presentatton.Submission & Return
The submission is online via moodle where you provide the link to the github page which contains
your report, code, hardware and links to social media. On the day of the deadline we will download
the latest release from the team’s github repository and mark it. It’s the responsibility of the team to
create a release on github by the deadline.
Make sure that each group member’s area of responsibility is clearly marked.
Note that University policy on late submission of work without good cause is that the grade will be
reduced by two secondary bands (e.g. from ‘B1’ to ‘B3 or ‘A5’ to ‘B2’) for each working day, or part of
a working day, after the submission deadline. This means that if the team’s software release is
created late on github they will receive a late submission penalty. Releases created more than five
days after the deadline will receive an ‘H’ grade. If you are unable to submit work on time due to
good cause, you should contact us as soon as is possible to seek a deferral.
Submission deadline : 21 April 2025, 3pm
Results & Feedback
Feedback & results about the initial pitch will be available after the presentation.
You will receive feedback about your final work via email. This feedback will be structured according
the 4 marking criteria above covering the final work and will comment on every section.1. Presentation
Grade range A1, A2 A3, A4, A5 B1, B2, B3 C1, C2, C3 D1, D2, D3 E1, E2, E3 F, G, H
Aggregation
Score
22, 21 20–18 17–15 14–12 11–9 8–6 5–0
(maybe CR)
Delivery Could present at a
conference with no
further training
Confident delivery,
clear speech, no
hesitation, held
attention
Good delivery,
only minor flaws
such as hesitation
Significant lapses
in delivery but
satisfactory overall
Hard to follow
significant parts of
the talk
Couldn’t make out
anything without
difficulty
Impossible to learn
anything
Slides Of professional
conference quality
Excellent slides,
attractive
appearance,
information well
presented
Good slides, only
minor flaws such
as poor layout or
plots with illegible
axes
Some slides had
illegible text or
incomprehensible
illustrations
Poor slides, hard to
read or deduce
content
No effort made to
prepare
appropriate slides
No slides (consider
CR)
Originality A novel product
idea with clear
market appeal
Impressive idea
which is genuinely
novel
Idea appropriate to
the brief
Indea generally
satisfactory but not
clear what is
original here
Idea not clear and
hard to judge
Generally
inadequate or
incorrect content
No worthwhile
idea(consider CR)
Realtime Professional,
quantitative
realtime
assessment
Clear case for
realtime
processing
Satisfactory case
for realtime
processing. Mostly
qualitative.
Realtime demands
not completely
clear.
Poor case for
realtime procesing,
lacking major
aspects
Minimal
understanding of
realtime
processing.
No understanding
of realtime
processing.
Response to
questions
Supervisor learnt
from response to
questions
Confident and
informed response
to all questions
Good response to
questions but
occasionally
unconvincing
Satisfactory
response to most
questions
Had difficulty
answering most
questions
Required
prompting for any
answer
Unable to answer
any questions
satisfactorily2. Structure of the code
Grade range A1, A2 A3, A4, A5 B1, B2, B3 C1, C2, C3 D1, D2, D3 E1, E2, E3 F, G, H
Aggregation
Score
22, 21 20–18 17–15 14–12 11–9 8–6 5–0
(maybe CR)
Optimal choice of
classes (SOLID)
Classes have clear
responsibilies,
interfaces are
segregated to be
client specific,
dependency
inversion, obey the
Liskov
Substitution
Principle and
documented in an
intutive way.
Classes have clear
responsibilies,
interfaces are
segregated to be
client specific,
dependency
inversion, obey the
Liskov Substitution
Principle. Minor
issues but still
professional
production standard.
Generally
following the
SOLID principles
but either one is
violated or
documentation
does not
demonstrate that
they have been
taken into
consideration.
Some SOLID
principles haven’t
been applied and/or
there are violations
of the principle.
Documentation has
flaws which makes it
hard to see if/how
they have been
applied.
Serious flaws in
the
implementation
of SOLID and
most principles
haven’t been
applied. There is
little mention in
the
documentation
about the class
choices.
Not clear
whether SOLID
has been applied
or not. Some
aspects appear
to be applied but
there is no direct
evidence or
documentation
which makes it
clear.
No application of
SOLID or little to
mark at all.
Encapsulation of
data in classes
and safe use of
getters, setters,
callbacks and
data
management.
Clear public
interfaces are
defined, the data is
private and getters,
setters & callbacks
provide a safe
interface to the
client. Internal data
structures are
efficient and
provide fast
acccess /
compuation.
Public interfaces are
defined, the data is
private and getters,
setters and callbacks
provide a safe
interface to the
client. However,
some minor flaws for
example in terms of
safety, timing and
choice of internal
data structures.
Generally data is
encapsulated and
the internal storage
of data is
appropriate but
there smaller
issues with the
getters / setters,
not checking for
fault conditions or
the internal data
storage could be
more efficient.
Significant problems
with encapsulation
such as public
variables and no
fault checking. Data
storage/management
is inefficient.
Serious flaws in
encapsulation
with public
variables being
accessed, no
clear getter, setter
and/or callback
interfaces and
data is stored in
not appropriate
structures.
No
encapsulation in
the classes used
but classes work
by accessing
variables and
calling member
functions. No
use of public /
private variables
& members.
No classes used,
use of global
variables or classless
coding.
Failsafe memory
management
Memory
management is
completely leak
free.
Memory
management is leak
free but uses
new/delete where it
could be avoided.
Excessive use of
new/delete where
C++ instances and
copy constructors
could be used.
Clearly there is a
lack of care of
tidying up memory
allocations.
Serious flaws of
memory
management with
eventual crash.
Serious flaws in
memory
management
leading to out of
memory.
No memory
management at all
or nothing to mark.3. Realtime coding
Grade range A1, A2 A3, A4, A5 B1, B2, B3 C1, C2, C3 D1, D2, D3 E1, E2, E3 F, G, H
Aggregation
Score
22, 21 20–18 17–15 14–12 11–9 8–6 5–0
(maybe CR)
Assessment of
latencies in the
application
context and
appropriate
design decisions
Professional
quantitative
assessment and
tolerances leading
to clear coding
decisions
Good quantitative
assessment of the
realtime demands
leading to good
coding decisions
with small
omissions.
Correct assessment
of requirements
but smaller
shortcomings and
resulting smaller
issues in terms of
coding decisions.
Assessment of the
latencies partially
wrong or not
completely
considered and the
propose coding
framework is not
well thought
through.
Latencies not
seriously assessed
and thus no
justification of the
realtime coding
strategy.
Almost no effort to
research in into
latencies and their
knock on effect on
coding.
Achieved virtually
nothing (consider
CR)
Realtime coding Production level
realtime coding
using
threads/timers/sign
als and kernel
interrupts
Perfectly working
prototype but minor
shortfalls in
structure, doc or
reliability.
Solid realtime
coding but with
smaller coding
issues causing
small noticeable
latencies.
Realtime coding
has shortcomings in
responsiveness,
timing and
sampling of
signals.
Significant
shortcomings in the
realtime coding
resulting in long
latencies.
Design shows
major weaknesses
in realtime
processing utilising
delays / blocking
code..
Showed few or
none of the skills
expected of a
graduate (consider
CR)
Realtime event
handling
Production level
event coding with
clearly defined
callback handlers
and other async
operations
Perfectly working
prototype but minor
shortfalls how
events are passed
on, documented or
structured.
Solid event
handling but with
smaller problems
where interface
definitions might
hinder segregation
or re-use.
Event handling has
shortcomings
flexibility, memory
usage, safety and
fault detection.
Event handling is
buggy.
Significant
shortcomings in
event handling
where instead of
callbacks partially
polling is used or
other non-realtime
approaches.
Design shows
major weaknesses
in even processing.
No callbacks are
used but the code is
purely polling
based.
Showed few or
none of the skills
expected of a
graduate (consider
CR)4. Revision control and project management
Grade range A1, A2 A3, A4, A5 B1, B2, B3 C1, C2, C3 D1, D2, D3 E1, E2, E3 F, G, H
Aggregation
Score
22, 21 20–18 17–15 14–12 11–9 8–6 5–0
(maybe CR)
Revision control Professional use
revision control
with regular
commits,
branching &
merging
Good use of
revision control
with detailed
commits
Use of revision
control but
shortcomings in
commits and
development on
master
Only work on
master without any
safeguards and
shortcomings in
commits
Only few commits
on the master
branch with
generic comments.
Used github only
as an upload site
with no
collaborative effort
Achieved virtually
nothing (consider
CR)
Project
management
Exemplary; could
not have done
better with the
time and resources
available
High-quality
planning, made
excellent use of
time and resources
available
Good planning and
use of resources
with only minor
deficiencies
Satisfactory
planning but could
clearly have made
better use of
resources.
Poor planning and
use of resources;
did not always
follow directions
All over the place;
required continual
direction from
supervisor
Did only what the
supervisor told
him or her, if tha
Reliability /
Testing / Bug
fixing
Professional
testing approaches
with unit tests,
issue tracking,
fixing
Good test
scenarios which
unit tests
Satisfactory testing
and debugging but
smaller
shortcomings
Testing only in
some cases but
clearly some are
left out.
Poor testing just in
a qualitative
manner,
No explicit testing
but just report of
success.
Achieved virtually
nothing (consider
CR)5. Documentation and PR
Grade range A1, A2 A3, A4, A5 B1, B2, B3 C1, C2, C3 D1, D2, D3 E1, E2, E3 F, G, H
Aggregation
Score
22, 21 20–18 17–15 14–12 11–9 8–6 5–0
(maybe CR)
Quality of the
content
Professional level
of documentation
comparable to
other github prof
projects
Comprehensive
coverage with no
significant
omissions
Good coverage
with only minor
omissions
Covered much of
the project but
with significant
omissions
Major omissions;
large parts of
project not covered
Only a little
material relevant
to project
Nothing of
substance
(consider CR)
Illustrations and
video content
Worthy of
publication
Well-chosen,
illuminating and
attractively
formatted
illustrations and
excellent video
Good illustrations
that enhance the
report and an eye
catching video
Illustrations
satisfactory but
could be drawn or
chosen better; too
few illustrations.
Video could have
clearer message.
Poor illustrations
or mostly from
WWW. Video film
has low quality in
terms of narrative
and presentation.
Images only from
WWW or missing.
The video has a
poor quality or
missing.
No illustrations
(consider CR)
No video.
PR / social media
strategy / release
strategy
Perfectly devised
strategy on all
channels and
targeting the right
audience.
Well devised
strategy covering
all relevant
channels and target
audience.
PR strategy
reflects a good
amateur project
but has
shortcomings for a
prof product
PR OK for a local
group of friends
and followers but
has shortcomings
reaching beyond it
Poor PR just
involving a few
last minute posts
on social media.
No clear strategy.
PR strategy just
limited to github.
No PR (consider
CR)§1 Task Overview
Aims
Development and promotion of a product requiring realtime operation.
Objectives
Propose a product which requires realtime processing and solves a real world task
Select hardware connecting to a Raspberry PI as proof of concept
Develop realtime software in C++ as the main language (only web-pages in webbrowser
& mobile apps are allowed to use scripting languages)
Create, maintain, schedule and document the project using git version control, tests
and quality management
Promote the final product via github, social media and live demos
§2 Task Requirements
The task is to present an end user product which requires realtime processing. This will be
build around Linux on a Raspberry PI. It needs to be a project which solves a real world
problem, for example, watering plants while away on holiday or a mattress which senses if a
person sleeps well. Note, that whilst creative lateral thinking is always welcome in Masters
level courses, it is possible to take shortcuts in creating an application which mean that it is
no longer realtime, or is otherwise trivial in nature, and thus does not show mastery of the
Intended Learning.
In technical terms this means that the Linux system needs to measure physical values, plot
them on the screen, allow mouse interaction to change parameters and that it generates
meaningful outputs. All this in realtime. At the end you should have a standalone embedded
application which boots up and performs your chosen task.
Your task is to use data acquisition hardware, for example the sound card or on the
Raspberry PI sensor boards and digital sensors.
Main coding language must be C++. The operating system must be Linux. Code must be
written in an object oriented fashion with a testing framework i.e. unit testing. Only web
clients running in web browsers and mobile phone apps are permitted to be written in a
scripting language (PHP, js, Python, JAVA, swift, ...).
The code must be event driven -- either in userspace with callbacks and/or waking up
threads and/or interrupt driven in kernel space.
Form groups of five and every person should have a distinct role. On moodle is a wiki where
every team enters their names, matric numbers and links to github where their entire
project is hosted.Outcomes of the course. We set out here requirements for the work, which if you ignore will
ensure that your project does not fulfil the brief and is liable to receive few if any marks. In
particular the following criteria pose a strong risk that the group will receive zero marks:
• program goes into wait state and becomes unresponsive
• using wait statements to establish timing instead of switching threads, timers or load
balancing
• not using callbacks to process events
• single threaded loop with blocking and/or delaying code
• trivial work selling just with public relations but no substance
• no indication of version control and/or git “upload” just before the deadlline
• not using C++ as the main coding language (remember scripting is only allowed for
web clients within web-browsers and mobile phone apps)
Do not hesitate to discuss with the course co-ordinator any original approaches to the
assignment you are worried might be off-topic and thus could attract a very low grade.
§3 Formal contact hours and independent work
You’ll spend 33 hours in the lab under supervision. There are also 11 hours of lectures you
need to attend. In addition you’ll need to work both independently in the lab and do
independent study in the remaining 156 hours allocated to this class. This work requires a
high degree of independent work while the lab sessions shall be used to get advice, guidance
and feedback from both the academics and teaching assistants.
§3 Hardware purchases
The budget is £45 per team for orders via the electronics store and/or technician.
請加QQ：99515681 郵箱：
[email protected] WX：codinghelp
