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

Mechanical Engineering

Share With

---

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 power relay.
1.2	If the temperature at the compressor outlet exceeds 120?C for a contin uous period of greater than 4 seconds, open the power relay.
1.3	If the temperature at the evaporator inlet falls below 0?C, open the power relay.
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 relay.
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 relay.
1.8	If the fault conditions specified in functional requirements 1.1 - 1.7 are not true AND the compressor outlet temperature is below 70?C AND a start signal is received from the control room, close the power relay.

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 of the system to the control room every 3 seconds.

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 ID	Test ID	Test	Result	Date	Sign
1.1	1.1.1	Set the input stimuli to healthy levels (eg. Temp 1 = 40?C, Temp 2 = 40?C, Temp 3 = 40?C, Pressure 1 = 2000kPa, E-stop = open), send a start signal to the device and observe the contactor close. Increase temperature 1 to 145?C and observe the power relay open.

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 ID	Test ID	Test	Result	Date	Sign
IPT1.1	IPT1.1.1	Connect button between PB3 and ground. Press button and observe pressed FAULT state (value = 1) by using ipt get values com mand. Release button and observe HEALTHY state (value = 0) using the same command.

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 detection module.
IPT1.2	Read the voltage generated by pressure sensor 1 and compute the corre sponding pressure. Send this information to the fault detection module.
IPT1.3	Read the voltage generated by the temperature sensor 1 and compute the corresponding temperature. Send this information to the fault detection module.
IPT1.4	Read the voltage generated by the temperature sensor 2 and compute the corresponding temperature. Send this information to the fault detection module.
IPT1.5	Read the voltage generated by the temperature sensor 3 and compute the corresponding temperature. Send this information to the fault detection module.
IPT1.6	If a current less than 4mA or greater than 20.5mA is detected on any 4-20mA device, send an appropriate sensor error signal to the fault de tection module. If no fault is detected, send a healthy signal to the fault detection module.

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 information to the state machine module. Hardware faults should take precedence over subsequent fault conditions.
FD1.2	If the temperature of the compressor outlet exceeds 140?C, send a com pressor over temperature fault signal to the state machine module. The fault code should persist until the temperature falls below 70?C.
FD1.3	If the temperature of the compressor outlet exceeds 120?C for a continu ous period of greater than 4 seconds, send a compressor over temperature fault signal to the state machine module. The fault code should persist until the temperature falls below 70?C.
FD1.4	If liquid is detected at the compressor intake, send a compressor liquid fault signal to the state machine module.
FD1.5	If the pressure at the compressor intake falls below 700kPa, send a com pressor under pressure fault signal to the state machine module.
FD1.6	If the temperature of the evaporator inlet falls below 0?C, send a evap orator under temperature fault signal to the state machine module.
FD1.7	If the E-stop is pressed, send an E-stop fault signal to the state machine module.
FD1.8	If no fault conditions are detected, send a healthy signal to the state machine module.

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 state to OPEN.
SM1.2	If state machine is in fault state and no fault is detected, change state to waiting.
SM1.3	If the state is waiting and a start signal is received from the commu nications module, change state to healthy. Set output module state to CLOSED.

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, close the relay by setting PB10 to HIGH.
OPT1.2	If the state of the relay set by the state machine module is OPEN, open the relay by setting PB10 to LOW.

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 newPressure)
Temperature 1	void module fault detect set temperature1(float newTemperature)
Temperature 2	void module fault detect set temperature2(float newTemperature)
Temperature 3	void module fault detect set temperature3(float newTemperature)
E-stop status	void module fault detect set estop(healthState)
Error code (from inputs mod ule)	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