SWEN326 Project: Developing an Automatic Emergency Braking System

2    Problem Overview

Your group has been tasked with developing a new Automotive Emergency Braking System (AEBS) that will be added to standard passenger cars. The software will be responsible for managing braking mechanisms in response to detected obstacles, maintaining vehicle control, and providing an interface for system monitoring.

The term standard passenger cars is going to be doing some heavy lifting in this project as usually you’d need to develop this with a specific model in mind.  It’s worth noting the system described below doesn’t specify absolutely everything that could be specified in a genuine real vehicle system.  For example, there isn’t as much detail on specific sensor configurations as there may otherwise be.  It’s worth remembering that the purpose of this assignment is to give you experience developing in a safety-critical domain, and some of the actual specifics of the system can be assumed by groups as there is no real vehicle that the output of this assignment will be deployed to.

We’re going to, for the sake of making this manageable, abstract out some of that and you can make reasonable assumptions about the car that your AEBS will be deployed to.

2.1    Asking for Clarification

Where there are any ambiguities below that groups want clarification on, groups can ask on the Project One Discussion Forum on Nuku during Weeks 7 and 8. Please do not send emails asking for clarification directly to the course coordinator - and use the forum instead. This just ensures that there is no accidental contradictions made by the course coordinator in private replies!

Individuals may end up asking questions in the lab sessions, and we’ll try to answer as best as we can there, however we’ll also ask that the clarification question be asked on the forum and the forum answer will be the definitive answer.

3    The System

Note:  Measurements are in metric units as these are standard across the automotive industry globally.

3.1    Driver Interface Specifications

1.  Driver Information Display:

•  Auditory and visual alerts for system engagement and hazard proximity.

•  Controls for setting AEBS sensitivity and intervention thresholds.

•  Button to activate or deactivate the AEBS manually.

2.  Emergency Intervention Indicators:

• Visual and auditory alerts for immediate braking actions.

•  Feedback mechanism to inform the driver of system readiness and any maintenance needs.

Note: The interface should be not be complex, for two reasons.  Firstly, you don’t have time to develop a complex interface.  Secondly, these are interfaces that drivers’ need to be able to use in split-seconds without significant distraction from their main task of driving.  Complex could equal bad, in that case.  Please note:  you will not be judged on the UX design choices from a visual perspective, this is not a User Experience project.  User Experience is relevant as a topic from a hazard point of view, but I’m not going to make you on that aspect in the way I would have if this was a SWEN303 project.

3.2    Sensor Data Specifications and Frequency

1.  Radar and Lidar Sensors:

•  Collect data to detect objects and their speed relative to the vehicle.

•  Data format: distance in meters and speed in km/h.

•  Update frequency: every 100 milliseconds.

2.  Camera Systems:

•  Provide visual identification and classification of road objects (e.g., vehicles, pedestrians).

•  Update frequency: every 50 milliseconds.

3. Wheel Speed Sensors:

•  Measure the rotational speed of each wheel to assist in determining vehicle speed and skid condi- tions.

•  Data format: revolutions per minute (RPM).

•  Update frequency: every 10 milliseconds.

All sensors operate will need to operate with redundancy for continued functionality in the event of a single sensor failure.  As such,  your system should assume multiple inputs from redundant (faked) sensors.  Choose a redundant architecture.

3.3    Control Signal Specifications and System Response

1.  Braking System Control:

•  Frequency of control signals to the braking system:  at least every 50 milliseconds during active braking situations.

•  Execution check parameters:  Verify the activation of brakes by sensor feedback within 50 mil- liseconds.

•  Success criteria:  A braking command is considered successfully executed if the wheel speed re- ductions align with expected deceleration curves within a margin of error of ±5%.

•  Failure handling:  If the execution check fails, the system should attempt to apply corrective braking up to two additional times before escalating the alert to the driver.

3.4    Sensor Data Simulation and Value Ranges

•  Radar and Lidar Data:

—  Simulate object detection from 0.5 to 200 meters, with operational thresholds for detection accu- racy based on object size and weather conditions.

•  Camera Data:

—  Simulate object classification accuracy, considering varying light and weather conditions.

• Wheel Speed Data:

—  Simulate speed data from 0 to 250 km/h, with thresholds for rapid deceleration indicating potential braking or traction issues.

Hazard Mitigation Strategies: Implement fault detection, fault tolerance, and fail-safe mechanisms to handle abnormal sensor values or system failures, ensuring the vehicle can safely manage potential hazards, reducing the risk of accidents.

4    Forming Teams

We will use the ECS team signup tool: https://ecs.wgtn.ac.nz/cgi-bin/teamsignup.

The system will be open from 9:00am on Friday, 4th April to midday on Tuesday, April 8th.

Students can self-organise in teams of between 4 — 6 students.  Students may submit small groups of 1, 2 or 3 students, however, these small groups will be merged with other small groups to form groups of 4 — 6 students on the afternoon of Tuesday, April 8th.  The final group list will be released on the morning of Wednesday, April 9th.

It is not compulsory to do the group project. All students who wish to attempt the group project need to register in the team signup system to signal their intent to do the project.  Even if you don’t currently have a group, register as a group of one, and you will be added to a group on Tuesday, 8th April.

For the sake of your peers, if you join a team and then decide to not engage with the project, I request that you let both your team and me know as soon as you know you won’t continue.  This means that others aren’t frustrated and slowed down trying to contact you and rely on or facilitate your input.

Also note that students who do  not engage with the team throughout the process but instead turn up at the last minute and try to make last-minute additions will not receive good marks, as that is poor software engineering practice. See below for more details about that...

Students who have not registered in the team signup system will be assumed to be not attempting the group project and will not be placed in a team.  A mark of 0% will be awarded for this assignment.  There is no mandatory course requirement to get any marks in this assessment, and you may still pass the course by getting 50% or more of the overall course marks from the teaching-weeks test (which contributes 54%) and the assessment-period test (which contributes 16%).

Should you be ill during team the team formation period and need to be placed in a team after Wednesday, April 9th, please contact the course coordinator as soon as possible.  Students will not be added to teams after the mid-trimester break and once Week 8 (April 28th) has begun.

5    Resources

5.1    Time

Time is your greatest resource in this project, as it is for many others.  The assumption is that each individual will commit six hours per week for six weeks to this project, although note that the final week will best be spent working on the individual report submission, so groups should aim to have all of the group work completed by the end of week 11 at the latest.

5.2    AI

You may use AI however you deem fit, however, note that you are responsible for ensuring that the output of the AI tool is correct, and you should cite the tool used and the prompts used in a report appendix.

5.3    Languages

You may attempt this project in either Java or C or Rust.

The relevant coding standard is based on the Power of Ten rules, written up at: https://ieeexplore.

ieee.org/document/1642624. We covered these rules in the lecture on Thursday, 31st March.

David Pearce wrote up a version of these rules for Java,  and this version can be found at:  https: //nuku.wgtn.ac.nz/courses/19441/files?preview=2501635

6    Software Development Process Under ISO 26262 for AEBS

Developing a safety-critical automotive system such as an Automotive Emergency Braking System (AEBS) necessitates strict adherence to the ISO 26262 standard, which is specifically tailored for automotive electronic system safety.  This section elaborates on the key phases of the automotive software development process, integrating practical actions, automotive-specific examples, and industry-standard methodologies.

6.1    Planning Phase

The planning phase should start with the development of an Automotive Safety Plan that explicitly identifies the safety goals for the AEBS  and the Automotive  Safety Integrity Levels  (ASIL)  required  for various subsystems based on their risk assessments. This plan should include:

•  Allocation of resources, timelines, and specific roles focusing on automotive safety requirements.

•  A Requirements Management Plan that details procedures for capturing, analyzing, and maintaining automotive-specific requirements like real-time response and environmental adaptability.

•  A Verification Plan that outlines testing strategies for automotive scenarios, including dynamic braking tests and pedestrian detection simulations.

•  A Configuration Management Plan that describes version control systems and branching strategies suitable for automotive software development environments. 

6.2    Analysis and Design Phase

This phase involves the transformation of automotive safety requirements into a detailed system architecture. Utilize automotive-specific analysis tools such as:

•  Fault Tree Analysis (FTA): Focused on the AEBS to trace back the causes of critical safety failures, such as inadequate braking force or sensor failures.

The resulting design documents should include:

•  System and software architecture diagrams that represent not only the software components but also their interactions with automotive hardware such as sensors and actuators.

6.3    Development Phase

When you are developing your AEBS, use safety-critical practices such as:

•  Coding/design guidelines like the Power of Ten, which provide strict rules to prevent software faults in domains such as automotive environments.

•  Use static code analysis tools and techniques to check for potential coding issues and identify good test cases for code coverage.

6.4    Integration Phase

Normally you’d also need to integrate software components methodically, ensuring that the interactions between software and automotive hardware are robust and reliable. Key integration activities would normally include:

•  The use of Automotive Hardware-in-the-Loop (HIL) simulations to validate the interactions between the AEBS software and the vehicle’s actual braking hardware under realistic conditions.

•  Continuous integration practices that are adapted for the high reliability requirements of automotive software systems.

You are not really in a position to do this Integration Phase, as we don’t have space to teach it in  SWEN326.  You can create a simulator though to provide fakely-realistic sensor data though, for testing...

6.5    Verification and Validation Phase

This critical phase should focus on ensuring that the AEBS functions correctly across all intended operating conditions:

•  Conduct software testing, including unit tests for software modules and system tests that simulate real-world driving scenarios to ensure the AEBS meets all specified automotive safety requirements.

•  Also test how your AEBS performs when things go wrong, which is to say:  under fault conditions, such as sensor failures or unexpected environmental interferences.

6.6    Documentation and Continuous Improvement

This project is more documenting and testing than coding.

While many of us get into software engineering because we like coding, the documentation is more times than not where the big decisions are made and where the big mistakes can either be created or solved...

As such, groups need to maintain documentation throughout the development process.  In particular, the key thing I’ll be looking for is traceability from requirements to test cases and back again. This documentation is vital for ongoing maintenance and future system enhancements.

7    Tasks

The assessment objective is to develop a safety-critical software system.  To achieve this will require working together as a group to develop multiple software systems.

7.1    Group Agreement

Starting with the last part first,  this is a short group project, with only five weeks at most for actual development leaving at least a week for writing the report. As such, it’s important that all group members are committed to the group and can contribute regularly, and that group members aren’t left waiting for long for other group members to do what they promise to do.

With this in mind, groups should quickly write an agreement on how they will work together, that all group members should sign up to. This should include aspects such as:

• when the group will regularly meet and how the outcome of meetings will be recorded.

•  how tasks will be allocated, what information will be stored and how progress or delays on tasks will be reported. For example, this may be either minuted at a group meeting and posted where everyone can see the tasks or may be done via issue-tracking in a GitLab repository.

•  a schedule of how many hours per week each member is committing.  While the course assumes around 6 — 7 hours per week throughout the project, some group members may have peaks and troughs in their workload elsewhere which means they may need to redistribute these hours differently.   This information should be captured and the group’s work scheduled planned accordingly.

•  an agreement on how variations to the schedule will be communicated and documented.

Group members who are unable to uphold the agreement and don’t contribute their share of time and effort to the project will be marked down in both the group assessment and the individual assessment.

At a minimum,  groups should use  GitLab  as  a repository of code and documentation.   Groups  are encouraged to use issue tracking as well.

7.2    Software — Two Systems

The group needs to develop an automobile software system (herein called the  core  system) that does the functionality specified in section 3. The biggest challenge here is that you as a group do not have access to any hardware to test on and there is no pre-existing simulation framework to plug your new system into! This means that you will need to not  only develop software that can be deployed to automobiles to solve the core problem, but you will also need to develop a non-trivial amount of software to test the main system by putting it through its paces in realistic ways.

The simulation software will need to simulate redundant sensors and a simple simulation of the brakes and car and surrounding environment.

The key thing here is that the simulation software needs to put the core system through its paces and so can’t just send only ideal data where everything is perfect and the car is in no danger.  The core system needs to be able to mitigate and handle hazards and events on a real car journey, so the simulation software must be able to replicate things events like: sensor errors; sudden unexpected events such as — for example — moving objects crossing the road; or unexpected braking by vehicles in front.

7.3    Simulation and ISO 26262

The simulation software is distinct from the core system, as the simulation software does not need to adhere to the full development process outlined in ISO 26262.   Normally,  something  like  Part 8 of ISO 26262, which covers tool qualification, would be used as a standard for software used as a tool to test or verify an automotive software system, but that itself (the tool) isn’t intended for actual deployment in vehicles.

We have not taught ISO  26262 Part  8 in  SWEN326,  and  as  such,  you  do  not  need  to develop the simulation tool to this standard.

8    Group Assessment

Each group should submit everything they create. Instructions on how to package this all up will be provided closer to the time, but the two key documents I’ll be looking for is:

•  A single PDF called GroupID ProjectPlan.pdf.

•  A single PDF or spreadsheet called GroupID Requirements Trace.pdf (or .xlsx)

At the risk of stating the blindingly obvious, replace  GroupID with your actual Group ID... Note:  more detail to be added here before Week 7.

9    Report

The individual report is a critique of what your group developed and how the development process was followed.  The report is to be done individually and is your chance to reflect on what went well and what could have gone better in the development of the system.  In scope for discussion are:  documentation created, code generated, processes followed, infrastructure constructed, tests performed, and analyses conducted.

This report is what you will be assessed on. The group must make reasonable progress on the development of the system for you to have anything worthwhile to comment on in your reports.  It is important to note that reports that simply point out that things the team didn’t get around to doing are things the team should have done won’t score particularly highly, as that isn’t particularly insightful.

9.1    Format

The format of the report needs to follow these formatting principles:

•  maximum of 8 pages (not including the appendices - see below).

•  single column.

•  12pt font.

•  clearly state your: full name; student ID; and group ID at the top of the first page.

•  have six section headings:  Documentation;  Code;  Tests;  Infrastructure;  Process;  Improve- ments.

•  submit as a single PDF called ”StudentID report.pdf”

9.2    Coverage

Since you have at most eight pages in total to cover all of these six components, there is no expectation that you cover all possible issues – both positive and negative – that could be mentioned. Part of the challenge of this report is identifying a couple of issues per report component that are significant and that are worth focussing on.

Note:  while I’ve said this report is a critique, it’s important to understand that this does not mean you are restricted to only mentioning negative aspects.  Something that went well can also be a perfectly valid thing to state  in a critique.   The  key aspect  to  focus on  is to support your claim — whether it be a good, bad or both good and bad aspect of the project — with evidence.

The purpose of the report is neither marketing (e.g.  “everything was awesome and the system is great and nothing can possibly go wrong!”) nor self-flagellation (e.g.  “the system is terrible and a death trap and lots of things went wrong with the group!”), but rather to self-reflect on a learning exercise.

9.3    Appendices

You should include up to two appendices at the end of your report.  The first appendix is not needed if you did not use AI tools. The second appendix is needed for all reports and is key for grading your report. Neither appendix counts towards the 8-page limit.

1.  [Appendix A]: - State how you used AI tools (if you did use AI tools), which tools you used and the prompts that you used.

2.  [Appendix B]: - State your contribution to the group project and identify how you spent your time on the various group tasks and how you met the group agreement.  This should not be longer than one page.