Fill This Form To Receive Instant Help
Fill This Form To Receive Instant Help
Homework answers / question archive / MCHA3400 Software realisation and validation Introduction In this assignment, you are tasked with the design and implementation of the software portion of a SIL1 rated system
MCHA3400 Software realisation and validation
Introduction
In this assignment, you are tasked with the design and implementation of the software portion of
a SIL1 rated system. The safety instrumented system (SIS) is used to monitor the operation of an
air conditioning unit installed in a hazardous area. A number of possible hazardous related to the
air conditioner operation have been identified which should be monitored by the SIS. In the case
of a hazardous event, the SIS should safely shut down the system by disconnecting power from the
compressor.
Figure 1: Overview of the air condition system prosed for installation.
The V-model of project management will be used throughout this assignment for the design and
development of the software. As discussed in lectures, this model of management requires that methods
of testing should be determined during the design phase, before the software itself is realised. As such,
this assignment will emphasise the role of adequate test design and documentation throughout the
development cycle.
Hardware configuration
For the purpose of this assignment, you will deploy the developed software solution on the provided
STM32nucleo board. A number of caveats should be provided at this point:
? The provided hardware is NOT certified for deployment in safety-critical systems. You can,
however, source similar hardware that is suitable for safety-critical applications (https://www.
st.com/en/embedded-software/x-cube-stl.html).
? Similarly, freeRTOS is NOT certified for safety-critical applications. Again, it is possible to
source equivalent software packages which are rated for safety-critical applications (https://
www.highintegritysystems.com/safertos/).
2
MCHA3400 | System modelling and simulation
Given these disclaimers, the provided hardware and software are entirely adequate for prototyping the
software module of the safety system.
An overview of the selected sensors being used to monitor the system is shown in Figure 1. The
selected STM32 pins for interfacing with the hardware is shown in Figure 2.
Figure 2: Wiring diagram of the SIS.
Each of the temperature and pressure sensors produces a 4-20mA signal which is read as a voltage
using and ADC once passed through a 125? shunt resistor. The voltage generated by each of these
signals can be simulated using a potentiometers. The selected sensors have the ranges as indicated
below:
|
Sensor |
Minimum value |
Maximum value |
|
Pressure 1 |
0kPa |
5000kPa |
|
Temperature 1 |
0?C |
200?C |
|
Temperature 2 |
-50?C |
100?C |
|
Temperature 3 |
-50?C |
100?C |
Power is supplied to the compressor via a power relay which is controlled via the pin PB10. Logic
level HIGH closes the relay (applying power) whereas a logic level LOW opens the relay, stopping the
system. This is the same polarity as was used in lab 11. The emergency stop button is normally open
(NO), and connects the pin PB3 to ground when pressed.
Use of a normally open (NO) contactor for an emergency stop button is typically bad practice.
Rather, best practice is to use a normally closed contact, ensuring that cable breaks will also
trigger the emergency stop functionality|fail safe design! Use of a NO contactor in this task is
due to difficulty sourcing an NC micro push-button switch to suit the testing hardware used in
this lab.
Tip
Software template
You have been provided with a software template for the assignment solution that is similar to that
used in lab 11. You should use the provided structure which has pre-defined module boundaries and
a serial interface which is useful for testing.
3
School of Engineering, Discipline of Mechanical Engineering and Mechatronics
Design improvement (15%)
As mentioned in the embedded systems Lab 11 document, the provided code template has some room
for improvement. 15% of your possible grade in this assignment is tied to your ability to identify
some of these shortcomings and implement an improved solution. These improvements could include
the appropriate implementation of some more advanced functionality of the STM32 processor or the
RTOS. Examples may include use of DMA, events, timers, mutexes, multiple error reporting, amongst
others. Your solutions should still conform to the provided module boundaries so that the provided
serial interface continues to function. The input-output structure of pre-defined functions should not
be modified.
Submission instructions
Assignment 3 is due at 11:59pm, Friday 2nd June. Your submission will consist of a software, written
and demonstration component.
Software submission: Task 2 requires you to write a software solution for the air conditioner safety
system. Your solution should be constructed from the provided template and conform to the predefined module boundaries. All file names should remain as provided and the serial interface should
not be modified (this will be used for testing your solution).
Written submission: Task 1 and Task 3.1 require you to document your design and testing phases.
Scan your documentation into a single .pdf document called
assignment3 written.pdf. Please ensure that your solutions are organised in the correct order within
your pdf document. Include a list of your design improvements at the start of your pdf submission. If
you have not attempted any improvements, please specify that this is the case in your submission. Note
that you will not be awarded marks for any improvements that are not clearly listed. Please ensure
that your solutions are neatly presented and organised in the correct order within your document.
Examples of acceptable submissions include:
? Neatly handwritten on paper and scanned to a pdf,
? Neatly handwritten on a tablet (e.g., Surface, iPad) and saved to a pdf,
? Typed in a word processor (e.g., MS Word with equation editor) and exported to a pdf,
? Typeset in LATEX and compiled to a pdf.
If you written submission cannot be easily read, it will receive a grade of 0.
Warning
Don’t submit your initial working-out. Rewrite your solutions neatly in a logical order!
Hint
4
MCHA3400 | System modelling and simulation
Factory acceptance test: After submitting your software solution and documentation you will
attend a factory acceptance test (FAT) to demonstrate your solution. During this meeting, your
solution will be deployed to the HIL test rig and a series of test will be performed on your solution
to verify correct behaviour. The results will then be compared to your submitted documentation
to determine an appropriate grade. The testing procedure will be similar to that completed at the
end of lab 11. Please attend this session with a hard copy of your signed tests from task 3.1 and
ready to program the STM32 fixed to the HIL test rig using either the lab PCs or your own device.
The schedule for FAT testing is posted on Canvas. Please discuss directly with Dr. Joel Ferguson
(joel.ferguson@newcastle.edu.au) if you need to reschedule this appointment. The version of code used
for demonstration will be the same version uploaded on 2-June, so there no advantage in postponing
the demonstration.
Submission format: Add both your written and software solutions into a single .zip file called
studentNumber studentName assignment3.zip1 and submit this file to Canvas for assessment. Your
final .zip folder should include the following files:
MCHA3400 StudentName studentNumber Assignment3
assignment3 student template
bin
build
lib
RTE
src
makefile
STM32F446RETx FLASH.Id
assignment3 written.pdf
(root directory)
Figure 3: Expected workspace directory tree after completing the assignment.
1The expressions studentNumber and studentName should be replaced with your student number and name, respectively.
5
School of Engineering, Discipline of Mechanical Engineering and Mechatronics
Assignment task 1: Software design
The V-model of project management will be followed for the SIS software development and testing.
As studied in lectures, this model is useful in emphasising how code will be tested before it is written.
The following overall functional specification has been prepared.
|
Spec. ID |
Functional requirement |
|
1.1 |
If the temperature at the compressor outlet exceeds 140?C, open the |
|
1.2 |
If the temperature at the compressor outlet exceeds 120?C for a contin |
|
1.3 |
If the temperature at the evaporator inlet falls below 0?C, open the |
|
1.4 |
If liquid is detected at the compressor intake, open the power relay. |
|
1.5 |
If the compressor intake pressure falls below 700kPa, open the power |
|
1.6 |
If the emergency stop is pressed, open the power relay. |
|
1.7 |
If a hardware fault is detected for any of the sensors, open the power |
|
1.8 |
If the fault conditions specified in functional requirements 1.1 - 1.7 are |
For the task of detecting liquid in the compressor intake, you have been provided with a function
float ref 410a sat pressure(float temp C), defined in ref r410a props.c, which will evaluate
the saturation pressure of refrigerant R410A as a function of temperature. The function requires
temperature in degrees Celsius and returns the saturation pressure in kPa.
In addition to the above behavioural requirements, the safety system should provide the following
communications services.
|
Spec. ID |
Communication requirement |
|
2.1 |
Send a heartbeat signal containing the state and the current error code |
In order to send a heartbeat to the control room, use the provided function module comms heartbeat(),
defined in mod comms.c. This will generate a serial output which can be observed using coolTerm.
Task 1.1: Validation test design (10%)
Before moving onto the detailed software design, methods for testing each of the functional specifications should be determined. Using the format provided in the following table, construct some tests
for each of the provided functional requirements. For these tests, assume that you have the ability to
manipulate all of the physical inputs to the system. Tests akin to these will be used by your tutor
when performing the factory acceptance test (FAT) at the conclusion of this assignment.
6
MCHA3400 | System modelling and simulation
|
Spec |
Test |
Test |
Result |
Date |
Sign |
|
1.1 |
1.1.1 |
Set the input stimuli to healthy levels (eg. Temp |
This stage involves populating the ID and Test columns of the above table. The other columns are
populated at test time.
Task 1.2: Module test design (10%)
Similar to the architecture used in lab 11, the software architecture for the SIS is to conform the
structure shown in Figure 4.
Figure 4: Software architecture for safety system.
For each fo the software modules you should create tests that verify the correct behaviour. You have
been provided with a template for each of the specified modules, each with an internal structure predefined. Additionally, a number of serial commands have been implemented that may be useful for
writing tests for your code. A summary of the provided serial interface can be found in Table 1. As
in Task 1.1, your tests should be presented in a table of the following form:
|
Spec |
Test ID |
Test |
Result |
Date |
Sign |
|
IPT1.1 |
IPT1.1.1 |
Connect button between PB3 and ground. |
Only the ID and Test columns should be populated during this step. The remaining columns will
be populated during testing. Functional specifications for each of the software modules is provided
below.
Inputs module: The inputs module reads the raw inputs and interprets the underlying excitation
signal. It is also responsible for identifying hardware faults related to the analogue sensors. Note that
fault codes for hardware faults have been pre-defined in fault codes.h.
7
School of Engineering, Discipline of Mechanical Engineering and Mechatronics
|
ID |
Module requirement |
|
IPT1.1 |
Monitor the status of the E-stop and update the status in the fault |
|
IPT1.2 |
Read the voltage generated by pressure sensor 1 and compute the corre |
|
IPT1.3 |
Read the voltage generated by the temperature sensor 1 and compute the |
|
IPT1.4 |
Read the voltage generated by the temperature sensor 2 and compute the |
|
IPT1.5 |
Read the voltage generated by the temperature sensor 3 and compute the |
|
IPT1.6 |
If a current less than 4mA or greater than 20.5mA is detected on any |
Fault detection module: The fault detection module is responsible to interpreting fault conditions
that may be experienced as part of the air conditioner operation. Note that all required fault codes
have been pre-defined in fault codes.h. You should not modify this list of pre-defined faults.
|
ID |
Module requirement |
|
FD1.1 |
If a hardware fault is detected by the inputs module, relay this fault |
|
FD1.2 |
If the temperature of the compressor outlet exceeds 140?C, send a com |
|
FD1.3 |
If the temperature of the compressor outlet exceeds 120?C for a continu |
|
FD1.4 |
If liquid is detected at the compressor intake, send a compressor liquid |
|
FD1.5 |
If the pressure at the compressor intake falls below 700kPa, send a com |
|
FD1.6 |
If the temperature of the evaporator inlet falls below 0?C, send a evap |
|
FD1.7 |
If the E-stop is pressed, send an E-stop fault signal to the state machine |
|
FD1.8 |
If no fault conditions are detected, send a healthy signal to the state |
8
MCHA3400 | System modelling and simulation
Make use of the provided function float ref 410a sat pressure(float temp C) to assist with
specification FD1.4.
Hint
State machine module: The state machine determines the mode of operation of the air conditioning
unit (on/off). The possible state of the state machine are pre-defined in mod state machine.h and
should not be modified.
|
ID |
Module requirement |
|
SM1.1 |
If a fault is detected, change state to fault state. Set output module |
|
SM1.2 |
If state machine is in fault state and no fault is detected, change state |
|
SM1.3 |
If the state is waiting and a start signal is received from the commu |
Outputs module: The outputs module controls the system outputs (power relay).
|
ID |
Module requirement |
|
OPT1.1 |
If the state of the relay set by the state machine module is CLOSED, |
|
OPT1.2 |
If the state of the relay set by the state machine module is OPEN, open |
Communications module: The communications module handles external communications to/from
the safety system (via the serial terminal). The start signal has already been implemented to call
module comms start received() when called, which will set the start received flag in the state
machine module.
|
ID |
Module requirement |
|
COM1.1 |
Generate a heartbeat signal every 3 seconds. |
|
COM1.2 |
If a start signal is received, send signal to the state machine module. |
Interface functions: The functions listed below are pre-defined within the appropriate modules and
can be used to pass information between modules according to the provided specifications. These
function definitions should not be modified.
9
School of Engineering, Discipline of Mechanical Engineering and Mechatronics
|
Fault detection module |
Interface function |
|
Pressure 1 |
void module fault detect set pressure1(float |
|
Temperature 1 |
void module fault detect set temperature1(float |
|
Temperature 2 |
void module fault detect set temperature2(float |
|
Temperature 3 |
void module fault detect set temperature3(float |
|
E-stop status |
void module fault detect set estop(healthState) |
|
Error code (from inputs mod |
void module fault detect set error(errorCode) |
|
State machine module |
|
|
Error code |
void module state machine set fault(errorCode) |
|
Start signal |
void module state machine start signal(void) |
|
Outputs module |
|
|
System health status |
void module outputs set state(relayState) |
|
Communications module |
|
|
Start signal |
void module comms start received(void) |
|
Heartbeat signal |
void module comms heartbeat(void) |
10
MCHA3400 | System modelling and simulation
Assignment task 2: Module realisation (50%)
The overall system design is complete and the methods of testing each module has been determined.
Your next task is to realise the software to conform to the above specifications. Due to the modular nature of the design and testing specifications, each software module can be written and tested
independently (ie. you should complete this task in conjunction with Task 3.1).
Note that the marks for this section will be assigned based on the correct functionality of each of the
modules, which will be verified by your tutors after submission, and the quality of the submitted code
(formatting, comments etc.).
11
School of Engineering, Discipline of Mechanical Engineering and Mechatronics
Assignment task 3: Software testing and system validation
Now that each of the modules have been written, our software development using the V-model is
almost complete. The final step is to verify correct behaviour of the system. This will be done in two
ways. Firstly, you will perform your own testing according to the previously specified tests. Then,
a factory acceptance test will be performed by your tutors using processor-in-the-loop (PIL) and
hardware-in-the-loop (HIL) testing.
Task 3.1: Module testing and documentation (15%)
Perform each of the tests specified in Task 1.2 and Task 1.1 (in that order). Note that for the validation
tests (Task 1.1), you can use the provided hardware (potentiometers, buttons, LED) to simulate the
inputs. For each test, it should be specified if the test passed or failed and then signed off. If an error
is found, the code should be corrected and all tests performed again on the corrected version. Once
completed, the code should not be modified further.
Your tutors will re-test your module functionality, ensuring that you are accountable for the code
that you are certifying. Marks will be awarded for the proportion of tests certified as passing at
time of testing. Marks will be deducted for functionality that was certified as working but found
non-functional during FAT.
Task 3.2: Factory acceptance test (0%)
The final stage of verification will be to undergo a factory acceptance test (FAT). This will be a
hardware-in-the-loop (HIL) test performed by one of your tutors after submission. As was done in the
lab 11, your code will be downloaded onto the HIL test rig and executed. The test rig will act as an
interface between your programmed logic controller and a Matlab simulation of the air conditioning
system. This will test the overall functionality of your system, ensuring that is conforms to the
provided specifications. During this meeting marks will be assigned for all prior tasks.
Figure 5: HIL testing rig.
12
MCHA3400 | System modelling and simulation
Table 1: Serial commands that can be used for testing software modules
Command format Description
start Start signal to the system by calling
module comms start received().
reset Reset the processor.
ipt_start Starts the input module thread by calling
module inputs start().
ipt_stop Starts the input module thread by calling module inputs stop().
ipt_get_values Displays the current input values to the console by calling
module fault detect print inputs().
fd_start Starts the fault detection module thread by calling
module fault detect start().
fd_stop Stops the fault detection module thread by calling
module fault detect stop().
fd_set_pressure1 Set pressure 1 value entering the fault detection module by calling
module fault detect manual pressure1().
fd_set_temp1 Set temperature 1 value entering the fault detection module by
calling module fault detect manual temperature1().
fd_set_temp2 Set temperature 2 value entering the fault detection module by
calling module fault detect manual temperature2().
fd_set_temp3 Set temperature 3 value entering the fault detection module by
calling module fault detect manual temperature3().
fd_set_estop Set estop state entering the fault detection module by calling
module fault detect manual estop(). 0=healthy, 1=fault.
fd_set_error Set error state entering the fault detection module by calling
module fault detect manual error().
sm_start Starts the state machine module thread by calling
module state machine start().
sm_stop Stops the state machine module thread by calling
module state machine stop().
sm_set_error Set the error state entering the state machine by calling
module state machine manual error().
opt_start Starts the outputs module thread by calling
module outputs start().
opt_stop Stops the outputs module thread by calling
module outputs stop().
opt_set_state Set the state of the output module by calling
module outputs manual state(). 0=OPEN, 1=CLOSED.
com_start Starts the comms module thread by calling
module comms start().
com_stop Stops the comms module thread by calling module comms stop().
13
