Communication Protocols

 

The main purpose of this environment is keep all the subsystems informed of any changes in the design parameters. Therefore, passing information between the subsystems is the most important part of this environment. To be able to control the information flow, some protocols were developed to enable the communication between these subsystems in an organized manner. In our design, all subsystems communicate through the CI which is responsible for passing the information to the subsystems that need to know.

There are two types of events that can occur in this system:

1. Change reported from one of the subsystems.
2. Request for data from one subsystem to another.

Figure 32 shows the protocol used for the first event represented by a finite state machine (FSM). The states of this FSM are:

1. Steady state: Do nothing.
2. Change has been reported: send lock message to all subsystems. Apply relations and check constraints. If constraints are satisfied, go to state 3. If constraints are not satisfied, report these to sender and go to steady state.
3. Constraints are satisfied: Notify the subsystems with the changes and wait for acknowledgments.
4. Acknowledgments received from all subsystems: Send the final acknowledgment to the subsystems and go to steady state.
5. Acknowledgments not Ok: Send a ``change-back'' command to the subsystems and go to steady state.

 
Figure 32: Finite state machine representation for the change protocol.  

Figure 33 shows the protocol for the second event. The states in this FSM are:

1. Steady state: Do nothing.
2. Request for S2 received from S1. Send the request to S2.
3. Required data found at S2. Send data to S1 and go to steady state.
4. Required data not found at S2. Send report to S1 and go to steady state.

 
Figure 33: Finite state machine representation for the data request protocol.  

The suggested protocol can be described in algorithmic notation as follows:

  do while true
     if change reported then
         lock messages
         apply relations
         check constraints
         if constraint satisfied then
             report changes to subsystems
             wait for subsystems acknowledgment
             if all acknowledgments ok
                 update database
                 report the new status
             else
                 send a change-back message to subsystems
                 report failure to sender
         else
             report nonsatisfied constraints to sender
         send final acknowledgment to subsystems
     else if data-request reported then
         send request to the appropriate subsystem
         if data received then
             send data to sender
         else
             send negative acknowledgment to sender.

Figure 34 shows a possible scenario when applying this protocol. In this algorithm we assume that all system constraints are located in the CI; however, any subsystem may reject the proposed values by other subsystems due to some unmodeled constraints. This can happen either because there are some ``new'' constraints that are not reported to the CI, or because some constraints are too hard to be easily represented in the constraint format in the CI.

 
Figure 34: Possible scenario for the communication between the subsystems.