Gasp-o-matic design using pseudo code
 

The requirements specification is the same

No UML- language design diagrams are drawn or used expect state- transition diagrams

Architecture design is the same as to number of processors

Operating system used is the same used in rtos course

Only real change is that a message is not an integer but a data structure

This solution is not carefully checked, but gives a general idea

I prefer my own simple dynamic memory allocation for messages and alarms, it
is not presented here. Simply, at pseudo code level it means calls as  ptr=get_block();before creation of a new alarm and a communication message. (Deleting same way free_block(ptr).)
This pseudo code design is an example of so called functional design.
There are pros and cons with it. Because eventually, whatever the design method is, all code is sequential, implementation is simple based on these pseudo codes. We can't show clearly capsulation of data and operations to objects, however, we have capsulated something in processes.

Tasks are divided to processes using just common sense.
Clearly monitoring processor runs monitor task and alarm task (because monitoring finds alarming situation), control processor runs control task and receiving new parameters task for control, and user interface processor runs user input (knobs) process and display handling process (updating numeric displays and display memory for alarm window). All processors run communication in and out processes to implement a protocol.

Concurrence design produces the following set of processes (this is almost identical to original example):

Processor 1
processes: monitor, alarm, communication out, communication in

Processor 2
Processes: control, receive parameters, communication out, communication in

Processor 3
processes: user input, display, communication_out, communication_in

---

Processor 1

Monitor process

loop for ever {
        message=receive( monitor_box,monitor_interval);  /* We are polling sensors, interrupting sensors are also possible- then solution is even simpler */
        loop  (for sensor in set O2- sensor, CO2- sensor, Pressure- sensor) {

measured_value = read_sensor( sensor);
message = build_change_message(processor_number,display_box,sensor, measured_value );
send_message(communication_box, message);
if ( measured_value changes alarming status (on or off )) {
message = build_alarm_message(processor_number,alarm_box, sensor, alarm_event );
       send_message(communication_box, message);
}
}

}
 

Alarm process

Every alarm type has it's state transition structure.
State transition structure is input to run_sate_machine( );

structure is :

CURRENT_STATE
TIME_TO_NEXT_TIMEOUT

TABLE:
STATE1:EVENT1:ACTION1( ):NEXT_STATE1:
STATE2:EVENT2;ACTION2( ):NEXT_STATE2:
STATE3:EVENT3:ACTION3( ):NEXT_STATE3:
...............

One special case is, that the action must be to start a timer in a time which is sooner than the current setting.
 

loop for ever {

 

message=receive(alarm_box,timeout);
If ( message is not timeout message)
       timeout=calaculate_new_value( ); /* The same box is used for timeout and other messages, if message is not timeout, we must start timer again, later, with correct value "the rest of time"  */

case message_type  /* We act on different events affectin to alarms */

timeout_type:

  alarm= seek_timeouted_alarm( );
  run_sate_machine(alarm, state_structure,event=timeout);
  new_timeout=seek_next_timout_time(); /* From alarm data structures- state transition structures */
  timeout=new_timeout; /* This is next timeout time for some alarm */
 

monitor_event:

    if( change in an existing alarm situation)
      run_sate_machine(alarm, state_structure,event=change);
    if( new alarming event)
       build_up_new_alarm( structure_address, alarming_event );
       update_alarm_list( );
       send(display_box, new_display_info);

confirm_alarm:

    run_sate_machine(alarm, state_structure,event=confirm);

scroll:

  update_alarm_list( );
  send(display_box, new_display_info);
  seen_alarms=seek_all_seen_alarms ( );
  loop (alarm in seen alarm list)
    run_sate_machine(alarm, state_structure,event=seen);

}
 
 
 

---

Processor 2
Processes: control, receive parameter change, communication_out, communication_in

Control process

Parameters: I:E,tidal_volume,minute_volume,respiration_rate,inspiration_flow_rate

loop for ever {

/* We use receive to produce timeout */

if( changed flag on) {
                             replace_old_params_with_new ( );
                             calculate_timing_flow_rates( );

                            }
set_drive_gas(pause_flow_rate);
message=receive(timeout_box,pause_timeout);

set_drive_gas(inspiratory_flow_rate);
message=receive(timeout_box, ispiratory_timeout);

set_drive_gas(expiratory_flow_rate);
message=receive(timeout_box, expiratory_timeout);
 

}

Receive parameter change process

loop for ever {
 

message=receive(parameter_box,timeout=huge);
copy_parameters_ for_control ( ); /* common data area */
set_flag_on_for_control( );
}