specification & design of real-time systems fa 07 se 545...

Specification & Design of Real-time Systems

FA_07_SE_545: ERAU TEAM BLUE

Software Design Description

Automatic Production Environment

Christopher Griffis

Steve Harvey

Leonardo Matos

Jason McGuire

Sean Pfeifer

Caylyne Shelton

Software Design Specification for Automatic Production Environment Page i

Contents

CONTENTS ................................................................................................................................................................. I

DOCUMENT INFORMATION................................................................................................................................II

REVISION HISTORY ...............................................................................................................................................II

1 INTRODUCTION ....................................................................................................................................................1

1.1 PURPOSE ..............................................................................................................................................................1 1.2 SYSTEM OVERVIEW..............................................................................................................................................1 1.3 SCOPE ..................................................................................................................................................................2 1.4 DEFINITIONS, ACRONYMS AND ABBREVIATIONS..................................................................................................2 1.5 SUPPORTING MATERIALS .....................................................................................................................................3 1.6 DOCUMENT OVERVIEW ........................................................................................................................................4

2 ARCHITECTURE....................................................................................................................................................5

2.1 SYSTEM COMPONENTS .........................................................................................................................................5

3 MECHANISTIC DESIGN.......................................................................................................................................8

3.1 SYSTEM STATES ...................................................................................................................................................8 3.2 ENTITY RELATIONSHIPS .....................................................................................................................................13

4 DETAILED DESIGN .............................................................................................................................................14

Figure 1: Data Flow Diagram for All Software Modes .................................................................................................... 14 4.2 PROCESS DESIGN SPECIFICATIONS .....................................................................................................................15 4.2.1 Tasking Diagram .......................................................................................................................................15 4.2.2 PROC1.......................................................................................................................................................15 4.2.3 PROC2.......................................................................................................................................................17 4.2.4 PROC3.......................................................................................................................................................21 4.2.5 PROC4.......................................................................................................................................................22 4.2.6 PROC5.......................................................................................................................................................25 4.2.7 PROC6.......................................................................................................................................................26

4.3 SYSTEM MODES .................................................................................................................................................28 Figure 2: APE State Chart ................................................................................................................................................ 28 Auto Control Mode (Default Mode)................................................................................................................................. 29 Figure 3: Data Flow Diagram for the Auto Control Mode ............................................................................................... 29 User Control Mode........................................................................................................................................................... 30 Figure 4: Data Flow Diagram for the User Control Mode................................................................................................ 30

4.4 WEB INTERFACE ................................................................................................................................................31 4.4.1 Mockup for APE Web Interface Page “home.asp”....................................................................................31 4.4.2 Description of Mockups .............................................................................................................................32 4.4.3 Pseudo Code for APE Web Interface Page “home.asp” ...........................................................................33 4.4.4 GoAhead Web Component Function and Member Description.................................................................33

APPENDIX A – DATA DICTIONARY ..................................................................................................................38

APPENDIX B – REQUIREMENTS TRACEABILITY MATRIX .......................................................................40

Software Design Specification for Automatic Production Environment Page ii

Document Information

Category Information

Document ID Software Design Description: Automatic Production Environment

Document Owner FA_07_SE_545: ERAU TEAM BLUE

Revision History

Version Primary Author(s) Description of Version Date Completed

0.1 Caylyne Shelton Initial document template 10/22/07

0.2 Caylyne Shelton Modified document template 11/03/07

0.3 Caylyne Shelton Initial Draft 11/05/07

0.4 Caylyne Shelton Statecharts, Component Diagram, State Transition

Tables, and Design Rationale Added

11/06/07

0.5 Caylyne Shelton Web Interface Design and Pseudo Code, Algo-

rithms and Pseudo Code for Functions

11/07/07

0.6 Caylyne Shelton RTM Added 11/07/07

1.0 Chris Griffis Version for Inspection 11/08/07

1.1 Caylyne Shelton Inspection Re-work 11/15/07

Software Design Specification for Automatic Production Environment Page 1

1 Introduction

1.1 Purpose

The purpose of this Software Design Description is to clearly communicate the design for the Automatic

Production Environment system. The Software Requirements Specification for the Automatic Production

Environment document was utilized in developing this design document. Appendix A provides a trace-

ability matrix from the Software Requirements Specification through this Software Design Description.

This document describes the decisions, rationale, architectural design, mechanistic design, and detailed

design of the Automatic Production Environment system. This Software Design Description shall be

used as the basis for implementing the Automatic Production Environment.

During the development of the APE system, developers keep logs of their individual time spent working

on the APE system that will be compiled into the final project report. A set of pre-defined process scripts

are followed by the developers, which includes the following artifacts: Development Plan, Requirements

Document, Test Plan, Design Document, Configuration Management Document, Source Code, Test Re-

sults, and a User's Manual. The developers use the facilities of RTLab (LB131) and Guidant Lab

(LB160), and the Tornado/VxWorks (Arcom) is the primary tool used for development. Developers shall

write code that conforms to the defined C language coding standard.

1.2 System Overview

The Automatic Production Environment system mimics the operation of an airport luggage conveyor belt

system, providing the functionality to transfer luggage on a conveyor belt system (comprised of two con-

veyor belts)and scan it (to simulate a luggage security scan). The system is constructed with Fischertech-

nick blocks and consists of the two conveyor belts- each driven by a motor, a motor driven pushing de-

vice, four scanners, and a scan motor. The Automatic Production Environment will transfer a luggage

item from one end of a conveyor belt to the other, then “scan” the item, and transfer it to the second con-

veyor belt via the pushing device, and then the second conveyor belt will move the luggage item to the

final destination point. The system will meet the specified timing, transition, and motion requirements

provided in the Software Requirements Specification document. The APE software, with the exception of

the webpage component, runs on the Arcom-Gx1 Target computer and an RS232 serial connection is

utilized to read sensors and send commands to actuators. A user can control the system from a web page

on the terminal computer via the Target Computer’s static IP address. The entire system is composed of

the Arcom-GX-1 target, the conveyor belt system, and a computer terminal. Please see Figure 1 for a

logical component layout. Yellow circles in Figure 1 depict acceptable areas that packages may be

placed, and packages can only be placed in the system when the system is in idle or off. A package can

only be removed from the system if the system determines it to be in the END PLACE. To detect a

package, the SCANNERPLACE must be in the “down” position. A timeout of five seconds has been set

to limit scan and push time. Push and Scan are atomic cycles in the system. Only one belt may be mov-

ing at any time in the system.

Figure 1 illustrates the physical layout of the system as a set of logical components.


Figure 1: Logical Component Layout

1.3 Scope

The design diagrams, design decisions, and rationale covered in this document describe how the Auto-

matic Production Environment system will be implemented. Design decisions are based on the require-

ments that have been specified for this system. This document makes no assumptions about the systems

requirements and serves only as a communication tool to describe how to implement the requirements

specified. This document uses accepted design notations (UML, Data Flow, etc.) and does not use any

proprietary notations.

1.4 Definitions, Acronyms and Abbreviations

Active – a motor is active if the motor is powered and turning.

APE – Automatic Production Environment.

Auto Control Mode – the default software mode in which control of the system occurs automatically and

without user intervention.

BELT1 – see Figure 1; the conveyor belt driven by Motor1.

BELT2 – see Figure 1; the conveyor belt driven by Motor2.

Data Dictionary – a listing of the data types and their respective descriptions as used in the system.

Detect – the sensor “detects” an object if the light path is occluded such that the sensor does not detect

light, therefore detecting an occluding object instead.

END PLACE – see Figure 1; the last logically detectable position the package can be in.

Extended – the pusher moves to “extended” when it pushes the object away from SCAN PLACE towards

the TRANSITION PLACE.


Home – a scanner in the home position is the most retracted position as detectable by the position switch

such that the package can enter the scanning area. The pusher in the home position is in the furthest most

position from the transition area as detectable by the position switch and is such that the package can

enter the scanning area.

Inactive – when the motor is not moving because it is not being powered, it is considered inactive.

M1 – see Figure 1; Motor1, drives BELT1;

M2 – see Figure 1; Motor2, drives BELT2.

M3 – see Figure 1; Motor3, drives the scanner.

M4 – see Figure 1; Motor4, drives the pusher.

No detect – the sensor does not detect an object if the light path is not occluded such that the sensor does

detect light, therefore not detecting an occluding object.

Package – the object used to model the payload that is acted upon in the APE system.

Pusher – the apparatus used to move a package from the SCAN PLACE to the TRANSITION PLACE.

S1 – see Figure 1; line sensor1.




SCAN PLACE – see Figure 1; the next sequentially and logically detectable position a package can have

in the system after being moved by BELT1 away from START PLACE. A package can be scanned only

if it is detected in the SCAN PLACE.

Scanner – the apparatus used to model the system’s ability to scan a package.

Scanning – the scanner is in its lowered position such that it triggers the position switch to detect such a

position.

START PLACE – see Figure 1; the first sequentially and logically detectable position a package can

have in or when being introduced to the system.

TC – Target Computer.

TRANSITION PLACE – see Figure 1; the next sequentially and logically detectable position the pack-

age can be in after it has been scanned and pushed onto BELT2.

User Control Mode – the alternate software mode in which automatic control of the system is suspended

to allow the user direct control over the system monitors.

1.5 Supporting Materials

[1] FA_07_SE_545 ERAU TEAM BLUE, “Software Requirements Specification Automatic Production

Environment.” SE545 SRS 10/24/2007, Version 2 – Post Inspection Release. Fall 2007.

[2] Hofmeister, Christine, Nord, Robert, and Soni, Dilip. Applied Software Architecture. Canada: Addi-

son Wesley Longman, Inc., 1999.

[3] Kornecki, Dr. A.J., “Embry-Riddle Real Time Class Resource: Description of the SE545 Project.”

SE545 Project System Description 08/10/2007, Version 01 – draft 1. Fall 2007.


[4] Software Engineering Standards Committee of the IEEE Computer Society, “Recommended Practice

for Software Design Descriptions,” IEEE Std. 1016-1998. 3 September 1998.

1.6 Document Overview

This document follows the document outline specified by the IEEE Std. 1016-1998, “Recommended

Practice for Software Design Descriptions,” with some modifications to tailor the document for the scope

of the Automated Production Environment system. This document proceeds first with the Architecture of

the APE system. This is followed by the Mechanistic Design of the system and then the Detailed Design

as well. Screenshots for the web interface to control the APE system are provided in this document. A

requirements traceability matrix is also provided, to link design decisions to the corresponding require-

ments specifications.


2 Architecture

2.1 System Components

The APE consists of six components, four of which each run a separate process (SensorPolling, Status-

Manager, MotorControl, and WebPage) and two of which run in the same process mutually exclusive of

each other (AutoControl and UserControl), eight components which retrieve system data that the Sensor-

Polling component depends on for sensor data (S1, S2, S3, S4, ScanDown, ScanHome, PushHome, and

PushExtend), and four components that depend on the MotorControl component to pass them commands

(M1, M2, M3, and M4). See Figure 2 for a component diagram of the APE system and Figure 3 for a

context diagram.

SensorPolling handles polling tasks for all of the sensor and sensor switch components. This design deci-

sion results in strong cohesion within the SensorPolling component as well as the sensor and sensor

switches, as each of the components need only be concerned with the functionality specific to the actuator

in which they interface.

MotorControl handles all commands to the four motor components. This reduces the coupling between

the motor components and the components issuing a command to them.

The design efforts made to achieve high cohesion and low coupling kept maintainability and understand-

ability in mind. Maintenance time is substantially lower for components with low coupling and therefore

coupling was reduced at all times possible.

Figure 2 is a component diagram, depicting the components and their dependencies that comprise the

APE system.


Figure 2: APE System Component Diagram

Figure 3 is a system context diagram, which depicts the relationship of the hardware sensor and actuator

components in correlation with the Logical Component Layout and Real-time Software Control.


Figure 3: APE System Context Diagram


3 Mechanistic Design

3.1 System States

This section describes the elements of the APE architecture in further detail, including the message inter-

actions and processes. Figure 4 provides a state chart diagram to illustrate the processes running concur-

rently while the APE system is in use. Automatic Control Mode and User Control Mode are mutually

exclusive. Automatic Control Mode receives signal data from the SensorPolling component. User Con-

trol Mode receives data from the WebPage component based on the user’s commands it receives.

Figure 4: System Running State Chart Diagram

Table 1 describes all events that which are defined by states occur in the system control process and how

they are handled depending on the current state. In this table, WaitFlag denotes a boolean identifier that

can either be T for True or F for false. When WaitFlag is set to True, this is an indicator that the process

is in a timed waiting state until the timer reaches its deadline and the flag is set to false. S1, S2, S3, and

S4 are the four sensors in the system, as previously defined, and they can either be D for disengaged or

nothing detected, or E for engaged or something detected. Motor1 and Motor2 can either be D for disen-

gaged or E for engaged. The Pusher and Scanner may either be D for disengaged, F for Engaged in the

Forward direction, or B for engaged in the backward direction. The “S2” Timer, “Scanner” Timer, and

“ExitScanner” Timer are separate timers that have unique return events.

System Running

Polling Sensors

Control Processing

Controlling Motors

Manual Control

Auto Control

Web Interfacing

Running

Sensor Input

Motor Control


Table 1: State Transition Table for Control Process

Current State

Description Event Response Next State

Object At S1

S1=D, S2=D, S3=D, S4=D,Motor1=D, Motor2=D, Scan-ner=D, Pusher=D, Con-trol=Auto

S1 Engaged Send Motor1Start Event Object Moving to S2

Object Mov-ing to S2

S1=D, S2=D, S3=D, S4=D,Motor1=E, Motor2=D, Scanner=D, Pusher=D, Control=Auto

S2 Engaged Send Motor1Stop Event

Object At S2

Object At S2

S2=E, S3=D, S4=D, Motor1=E, Motor2=D, Scanner=D, Pusher=D, WaitFlag=F, Con-trol=Auto

Motor1 Disengaged Set "S2" Timer for 2 secs, set WaitFlag=T

Object Waiting For Scan

Object Wait-ing For Scan

S2=E, S3=D, S4=D, Motor1=D, Motor2=D, Scanner=D, Pusher=D, WaitFlag=T, Con-trol=Auto

"S2" Timer Expired Set WaitFlag=F, Send Scanner Move Forward Event

Object Scanning

Object Scan-ning

S2=E, S3=D, S4=D, Motor1=D, Motor2=D, Scanner=F, Pusher=D, WaitFlag=F, Con-trol=Auto

Scanner Reached Down Position

Send Scanner Stop Event, Set "Scanner" Timer for 10 secs, set WaitFlag=T

Scanner Read

Scanner Read


"Scanner" Timer Expired Set WaitFlag=F, Send Scanner Move Back-ward Event

Scanner Retrack

Scanner Retrack

S2=E, S3=D, S4=D, Motor1=D, Motor2=D, Scanner=B, Pusher=D, WaitFlag=F, Con-trol=Auto

Scanner Reached Home Position

Send Scanner Stop Event, Set "ExitScan-ner" Timer for 5 secs, set WaitFlag=T

Object Waiting To Leave Scanner

Object Wait-ing To Leave Scanner


"ExitScanner" Timer Ex-pired

Set WaitFlag=F, Send Pusher Move Forward Event

Object Moving to S3


S3=D, S4=D, Mo-tor1=D,

Motor2=D, Scan-ner=D,

Pusher=F, Wait-Flag=F,

Control=Auto

Pusher Reached Extend Position

Send Pusher Move Backward Event

Pusher Finishing OR Pusher Not Finished

Pusher Not Finished

S3=D, S4=D, Mo-tor1=D,

Motor2=D, Scan-ner=D, Pusher=B, Con-trol=Auto

Pusher Reached Home Position

Send Pusher Move Forward Event

Object Moving to S3


Current State


Pusher Finishing

S3=E, S4=D, Mo-tor1=D,


Pusher=B, Con-trol=Auto

Pusher Reached Home Position

Send Pusher Stop Event

Object at S3

Object at S3

S3=E, S4=D, Mo-tor1=D,


Pusher=B, Con-trol=Auto

Pusher Stopped Send Motor2 Start Event

Object Moving to S4


S4=D, Motor2=E, Control=Auto

S4 Engaged Send Motor2 Stop Event

Object at S4

Manual Motor1 Disengaged

Motor1=D, Con-trol=Manual

User Request for Start Motor1 Received

Send Motor1 Start Event

Manual Motor1 En-gaged

Manual Motor1 Engaged

Motor1=E, Con-trol=Manual

User Request for Stop Motor1 Received

Send Motor1 Stop Event

Manual Motor1 Disen-gaged

Manual Motor2 Disengaged

Motor2=D, Con-trol=Manual

User Request for Start Motor2 Received

Send Motor2 Start Event

Manual Motor2 En-gaged

Manual Motor2 Engaged

Motor2=E, Con-trol=Manual

User Request for Stop Motor2 Received

Send Motor2 Stop Event

Manual Motor2 Disen-gaged

Manual Scanner Not Moving Forward

Scanner=D or Scan-ner=B,

Control=Manual

User Request for Scanner Move Forward Received

Send Scanner Move Forward Event

Manual Scanner Moving Forward

Manual Scanner Not Moving Forward

Scanner=D or Scan-ner=F,

Control=Manual

User Request for Scanner Move Backward Received

Send Scanner Move Backward Event

Manual Scanner Moving Backward

Manual Scanner Engaged

Scanner=B or Scan-ner=F,

Control=Manual

User Request for Scanner Stop Received

Send Scanner Stop Event

Manual Scanner Disen-gaged

Manual Pusher Not Moving Forward

Pusher=D or Pusher=B,

Control=Manual

User Request for Pusher Move Forward Received

Send Pusher Move Forward Event

Manual Pusher Moving Forward

Manual Pusher Not Moving Forward

Pusher=D or Pusher=F,

Control=Manual

User Request for Pusher Move Backward Received

Send Pusher Move Backward Event

Manual Pusher Moving Backward

Manual Pusher Engaged

Pusher=B or Pusher=F,

Control=Manual

User Request for Pusher Stop Received

Send Pusher Stop Event

Manual Pusher Disen-gaged

Auto idle

S4=D, Motor1=D, Motor2=D, Scanner=D, Pusher=D, Control=Auto

User Request for Manual Mode Received

Toggle Manual Mode Manual Mode

Manual Mode

Control=Manual User Request for Auto Mode Received

Toggle Auto Mode Auto Mode


The four motor control components are illustrated in Figure 5 as the separate states that can occur based

on the commands from the MotorControl process. In either Automatic or User Control Mode, all four

motor components are continuously receiving commands from the MotorControl component. When a

motor control component is not receiving and executing a command, it is in the idle state.

Figure 5: Motor Control State Chart Diagram

Motor Control

Scanner Pusher Motor2

Disengaged

Motor1

Engaged

Disengaged

Engaged

Disengaged

Moving to extend

Moving to home

Disengaged

Moving to scan

Moving to home


Table 2 describes all events that occur in the Motor Control process and how they are handled depending

on the current state. In this table, Motor1 and Motor2 can either be D for disengaged or E for engaged.

The Pusher and Scanner may either be D for disengaged, F for Engaged in the Forward direction, or B for

engaged in the backward direction.

Table 2: State Transition Table for Motor Control Process

Current State


Motor1 Stopped

Motor1=D Motor1 Start Event Received Start Motor1 Motor1 Started

Motor1 Started

Motor1=E Motor1 Stop Event Received Stop Motor1 Motor1 Stopped

Motor2 Stopped

Motor2=D Motor2 Start Event Received Start Motor2 Motor2 Started

Motor2 Started

Motor2=E Motor2 Stop Event Received Stop Motor2 Motor2 Stopped

Scanner Not Moving For-ward

Scanner=D or Scan-ner=B

Scanner Move Forward Event Received

Start Scan-ner in For-ward Direc-tion

Scanner Moving For-ward

Scanner Not Moving Backward

Scanner=D or Scan-ner=F

Scanner Move Backward Event Received

Start Scan-ner in Back-ward Direc-tion

Scanner Moving Backward

Scanner Moving

Scanner=B or Scanner=F Scanner Stop Event Received Stop Scan-ner

Scanner Not Moving

Pusher Not Moving For-ward

Pusher=D or Pusher=B Pusher Move Forward Event Re-ceived

Start Pusher in Forward Direction

Pusher Mov-ing Forward

Pusher Not Moving Backward

Pusher=D or Pusher=F Pusher Move Backward Event Received

Start Pusher in Backward Direction

Pusher Mov-ing Back-ward

Pusher Mov-ing

Pusher=B or Pusher=F Pusher Stop Event Received Stop Pusher Pusher Not Moving


3.2 Entity Relationships

To provide more detail extending from the Component Diagram (Figure 2), Figure 6 shows the entities in

the APE system and how they are related to one another.

Figure 6: APE Entity Relationship Diagram


4 Detailed Design

Figure 1: Data Flow Diagram for All Software Modes


4.2 Process Design Specifications

4.2.1 Tasking Diagram

4.2.2 PROC1

Process Design Specification for [PROC1]

Unique ID: [PROC1]

Name: Void sensorPoll(void)

Description: The “sensor polling process” periodically checks the signals from all 8 of the hardware

sensors and encodes this information into a “sensorStatusMsg” that serves as a snapshot

of all the sensor statuses

Inputs: Type: Enum Name: s1Signal Description: the signal from line sensor1

Type: Enum Name: s2Signal Description: the signal from line sensor2



Type: Enum Name: scanDownSignal Description: the signal from the scan down position switch

Type: Enum Name: scanHomeSignal Description: the signal from the scan home position

switch

Type: Enum Name: pushExtendSignal Description: the signal from the pusher extend posi-

tion switch


Type: Enum Name: pushHomeSignal Description: the signal from the pusher home position switch

Outputs: Type: Event Mes-

sage

Name: sensorStatusMsg Description: A message whose payload has all the

sensors’ status encoded in the data

Subprocess: Signature: Byte poll(void) Description: Polls the sensors, creates the byte encoded responses

Signature: void msgSend () Description: Sends the message to the appropriate queue

Algorithm: Byte poll(void) Poll s1 Set first bit in statusByte (index 0 in the payload of sensorStatusMsg) equal to Enum value from s1Signal (can only be 0 or 1 value). Poll s2 Set second bit in statusByte (index 1 in the payload of sensorStatusMsg) equal to Enum value from s2Signal (can only be 0 or 1 value). Poll s3 Set third bit in statusByte (index 2 in the payload of sensorStatusMsg) equal to Enum value from s3Signal (can only be 0 or 1 value). Poll s4 Set fourth bit in statusByte (index 3 in the payload of sensorStatusMsg) equal to Enum value from s4Signal (can only be 0 or 1 value). Poll scanDown Set fifth bit in statusByte (index 4 in the payload of sensorStatusMsg) equal to Enum value from scanDownSignal (can only be 0 or 1 value). Poll scanHome Set sixth bit in statusByte (index 5 in the payload of sensorStatusMsg) equal to Enum value from scanHomeSignal (can only be 0 or 1 value). Poll pushHome Set seventh bit in statusByte (index 6 in the payload of sensorStatusMsg) equal to Enum value from pushHomeSignal (can only be 0 or 1 value). Poll pushExtend Set eighth bit in statusByte (index 7 in the payload of sensorStatusMsg) equal to Enum value from pushExtendSignal (can only be 0 or 1 value). Call MsgQSend. void msgQSend() Set first bit in receiverByte (index 0) equal to 1 (to signify autoControl() is a receiver of sensorStatusMsg). Set second bit in receiverByte (index 1) equal to 1 (to signify statusManager() is a receiver of sensorStatusMsg). Set remaining six bits in receiverByte(indices 2, 3, 4, 5, 6, 7) equal to 0 (so that the sensorStatusMsg is not delivered to any other processes). Load receiverByte into sensorStatusMsg. Load statusByte into sensorStatusMsg. If msgQSensorToAutoControl exists

Send sensorStatusMsg to msgQSensorToAutoControl. Else Create msgQSensorToAutoControl. Add sensorStatusMsg to msgQSensorToAutoControl. If msgQSensorToStatusMgr exists Add sensorStatusMsg to msgQSensorToStatusMgr. Else Create msgQSensorToStatusMgr. Add sensorStatusMsg to msgQSensorToStatusMgr.

Pseudocode: Byte poll(void) statusByte[0] = s1Signal statusByte[1] = s2Signal statusByte[2] = s3Signal statusByte[3] = s4Signal statusByte[4] = scanDown statusByte[5] = scanHome statusByte[6] = pushHome statusByte[7] = pushExtend


void msgSend () recieverByte[0] = 1 receiverByte[1] = 1 for(i = 2; i < 8; i++) receiverByte[i] = 0 sensorStatusMsg += receiverByte sensorStatusMsg += statusByte if(msgQSensorToAutoControl!= nullptr) msgQSensorToAutoControl ->Add(sensorStatusMsg) else new msgQSensorToAutoControl msgQSensorToAutoControl->Add(sensorStatusMsg) if(msgQSensorToStatusMgr!= nullptr) msgQSensorToStatusMgr ->Add(sensorStatusMsg) else new msgQSensorToStatusMgr msgQSensorToStatusMgr ->Add(sensorStatusMsg)

Timing: Issue: input timing Deadline/Freq: All inputs arrive sequentially (but in no specified order) and are polled periodically, once per sensor during each

execution cycle.

Issue: output timing Deadline/Freq: Updated sensorStatusMsg sent at the end of every execu-tion cycle.

sensorStatusMsg sent to all recipients at the same time.

Issue: frequency of execution Deadline/Freq: 10Hz; once every 100ms

Issue: time of execution Deadline/Freq: no more than 10ms

Issue: concurrency Deadline/Freq: runs concurrently and continuously

Errors: Description: No outgoing message queue Response: Create an outgoing message queue

4.2.3 PROC2


Unique ID: [PROC2]

Name: autoControl()

Description: The “auto control process” has a predetermined table of responses for each possible sen-

sor signal combinations. Accepts a sensorStatusMsg, looks up the correct reaction and

sends out an autoControlMsg only if the current state of control needs to be changed.

May be disabled with a toggle input. Can only send outputs if system in automatic con-

trol mode.

Inputs: Type: Event Mes-sage

Name: sensorStatusMsg Description: A message whose payload has all the sensors’ status encoded in the data

Type: Event Mes-

sage

Name: toggle Description: request for releasing control to userCon-

trol() or returning control from userCon-trol()

Outputs: Type: Event Mes-sage

Name: autoControlMsg Description: Contains an actuator control command


Subprocess: Signature: Byte statusData(void) Description: Retrieves the statusByte data from the sensorStatusMsg

Signature: void msgSend () Description: Sends the message to the appropriate message queue

Algorithm: Byte statusData(void) If msgQSensorToAutoControl and msgQToggle exist Retrieve statusByte from sensorStatusMsg. Lookup response corresponding to statusByte data in Response Lookup Table and set commandByte equal to that value. If controlState is manual Send msgQToggle for userControl() to release semaphore. Repeat. Else controlState is automatic

Call msgSend. void msgQSend() Set first bit in receiverByte (index 0) equal to 0. Set second bit in receiverByte (index 1) equal to 1 (to signify statusManager() is a receiver of autoControlMsg).

Set third bit in receiverByte (index 2) equal to 1 (to signify motorControl() is a receiver of autoControlMsg). Set remaining five bits in receiverByte(indices 3, 4, 5, 6, 7) equal to 0 (so that the autoControlMsg is not delivered to any other processes). Load recevierByte data into autoControlMsg. Load response command data into autoControlMsg.

If msgQAutoToMotorQ exists Send autoControlMsg. Else Create msgQAutoToMotorQ. Send autoControlMsg.

Pseudocode: Byte statusData(void) if(msgQSensorToAutoControl != nullptr && msgQToggle != nullptr)

for(i = 0; i < 8; i++) statusByte += sensorStatusMsg[i] commandByte = GetResponse(statusByte) if(msgQToggle[0] == 0) msgQToggle->Add(toggle) break else msgSendQ()

void msgSend () receiverByte[0] = 0

receiverByte[1] = 1 receiverByte[2] = 1 for(i = 3; i < 8; i++) receiverByte[i] = 0 autoControlMsg += receiverByte autoControlMsg += commandByte if(msgQAutoToMotorQ != nullptr) msgQAutoToMotor->Add(autoControlMsg) else new msgQAutoToMotorQ msgQAutoToMotor->Add(autoControlMsg) if(msgQAutoToStatus != nullptr) msgQAutoToStatus->Add(autoControlMsg) else new msgQAutoToStatus msgQAutoToStatus->Add(autoControlMsg)

Timing: Issue: input timing Deadline/Freq: sensorStatusMsg arrives continuously and periodically.

toggle arrives sporadically and at different times than sen-

sorStatusMsg.

Issue: output timing Deadline/Freq: autoControlMsg sent sporadically.


autoControlMsg sent to all recipients at the same time.

Can only send autoControlMsg when in automatic control

mode.




Errors: Description: No incoming message queue Response: none

Description: No outgoing message queue Response: Create an outgoing message queue


Table 1: Response Lookup Table for [PROC2] autoControl()

s4 s3 s2 s1 motor1 motor2 scanner pusher

no de-tect

no de-tect

no de-tect

no de-tect inactive inactive inactive inactive

no de-tect

no de-tect

no de-tect

detect active inactive inactive inactive

no de-tect

no de-tect

detect no de-tect inactive inactive UC2 UC3

no de-tect

no de-tect

detect detect inactive inactive UC2 UC3

no de-tect

detect no de-tect

no de-tect inactive active inactive inactive

no de-tect

detect no de-tect

detect inactive active inactive inactive

no de-tect

detect detect no de-tect inactive active inactive inactive

no de-tect

detect detect detect inactive active inactive inactive

detect no de-tect

no de-tect


detect no de-tect

no de-tect

detect inactive inactive inactive inactive

detect no de-tect

detect no de-tect inactive inactive inactive inactive

detect no de-tect

detect detect inactive inactive inactive inactive

detect detect no de-tect


detect detect no de-tect

detect inactive inactive inactive inactive

detect detect detect no de-tect inactive inactive inactive inactive

detect detect detect detect inactive inactive inactive inactive


4.2.4 PROC3


Unique ID: [PROC3]

Name: motorControl()

Description: The “motor control process” accepts a control message (originating from either auto-

matic control or the user) and translates that into a command to stop or activate the ap-

propriate set of motors in the appropriate directions.

Inputs: Type: Event Mes-

sage

Name: autoControlMsg Description: Contains a control command originating

from the auto control process

Type: Event Mes-sage

Name: userControlMsg Description: Contains a control command originating from the user manually operating system.

Outputs: Type: Enum Name: motor1Command Description: Command instructing motor1 to move BELT1 forward or stop.

Type: Enum Name: motor2Command Description: Command instructing motor2 to move

BELT2 forward or stop.

Type: Enum Name: pusherCommand Description: Command instructing pusher to go ex-tended or home.

Type: Enum Name: scannerCommand Description: Command instructing scanner to go to

down position or to home position.

Subprocess: Signature: Byte command-

Data(void)

Description: Retrieves the commandByte data from the sensorStatusMsg

Algorithm: Byte commandData(void) If msgIncomingQ exists

If controlState is automatic Retrieve commandByte from autoControlMsg. Else controlState is manual Retrieve commandByte from userControlMsg. If the first bit in commandByte (index 0) is 1 and motor1 is not moving BELT1 Set motor1Command equal to 1 (moving BELT1). If the first bit in the commandByte (index 0) is 0 and motor1 is moving BELT1 Set motor1Command equal to 0 (stop moving BELT1). If the second bit in commandByte (index 1) is 1 and motor2 is not moving BELT2 Set motor2Command equal to 1 (moving BELT2). If the second bit in the commandByte (index 1) is 0 and motor2 is moving BELT2 Set motor2Command equal to 0 (stop moving BELT2). If the third bit in commandByte (index 2) is 1 and pusher is home Set the pusherCommand equal to 1 (extending pusher). If the third bit in commandByte (index 2) is 0 and pusher is extended Set the pusherCommand equal to 0 (pusher home). If the fourth bit in commandByte (index 3) is 1 and scanner is home Set the scannerCommand equal to 1 (scanner down). If the fourth bit in commandByte (index 3) is 0 and scanner is down Set the scannerCommand equal to 0 (scanner home).


Pseudocode: Byte commandData(void) if(msgQAutoToStatus != nullptr) if(controlState == 1) for(i = 0; i < 8; i++) commandByte += autoControlMsg[i] else for(i = 0; i < 8; i++) commandByte += userControlMsg[i] if(commandByte[0] == 1 && motor1 == 0) motor1Command = 1 if(commandByte[0] == 0 && motor1 == 1) motor1Command = 0 if(commandByte[1] == 1 && motor2 == 0) motor2Command = 1 if(commandByte[1] == 0 && motor2 == 1) motor2Command = 0 if(commandByte[2] == 1 && pusher == 0) pusherCommand = 1 if(commandByte[2] == 0 && pusher == 1) pusherCommand = 0 if(commandByte[3] == 1 && scanner == 0) scannerCommand == 1 if(commandBtye[3] == 0 && scanner == 1) scannerCommand = 0

Timing: Issue: input timing Deadline/Freq: autoControlMsg and userControlMsg arrive sporadically

and at different times.

Issue: output timing Deadline/Freq: Actuator commands (any of the outputs) are sent sporadi-

cally and independently of each other.





4.2.5 PROC4


Unique ID: [PROC4]

Name: userControl()

Description: The “user control interface” interprets a command sent from the webpage and translates

it into userControlMsg. A request for user control from the webpage will cause this

process to request control from the “auto control process [PROC2]” using a toggle mes-

sage. A request to return to automatic control from the webpage will cause this process

to return control to the “auto control process [PROC2]” using a toggle message. Can

only send userControlMsg if the system in user control mode.

Inputs: Type: Event Mes-sage

Name: userCommand Description: A user command sent from the webpage

Outputs: Type: Event Mes- Name: userControlMsg Description: Contains a control command originating


sage from the user manually operating system.


Name: toggle Description: Contains a request to have control or a request to return control

Subprocess: Signature: Byte userCom-

mand(void)

Description: Retrieves the statusByte data from the sensorStatusMsg

Signature: void msgSend () Description: Send the message to the appropriate message queue

Algorithm: Byte statusData(void) Retrieve controlByte from userCommand. Retrieve commandByte from userCommand. If userCommandByte is valid If controlState is autoControl and controlByte data corresponds to manual control mode Send toggle message for control released from autoControl(). If controlState is userControl and controlByte data corresponds to manual control mode Call msgQSend. If controlState is userControl and controlByte data corresponds to automatic control mode Send toggle message for control released from userControl().

void msgSend () Set first bit in receiverByte (index 0) equal to 0. Set second bit in receiverByte (index 1) equal to 1 (to signify statusManager() is a receiver of autoControlMsg). Set third bit in receiverByte (index 2) equal to 1 (to signify motorControl() is a receiver of autoControlMsg). Set remaining five bits in receiverByte(indices 3, 4, 5, 6, 7) equal to 0 (so that the autoControlMsg is not delivered to any other processes). Load receiverByte into userControlMsg. Load commandByte into userControlMsg. If msgOutQ exists

Send userControlMsg. Else Create msgOutQ. Send userControlMsg.

Pseudocode: Byte statusData(void) for(i = 0; i < 8; i++) controlByte += userCommand[i] for(i = 8; i <16; i++) commandByte += userCommand[i] if(userCommand->isValid()) if(controlState == 1 && controlByte == 0) toggle[0] = 0 msgQToggle->Add(toggle) if(controlState == 0 and controlByte == 0) msgQSend() if(controlState == 0 && controlByte == 1) toggle[0] = 1 msgQToggle->Add(toggle)

void msgSend () receiverByte[0] = 0 receiverByte[1] = 1 receiverByte[2] = 1 for(i = 3; i < 8; i++) receiverByte[i] = 0 userControlMsg += receiverByte userControlMsg += commandByte if(msgQuserToMotor != nullptr) msgQUserToMotor->Add(userControlMsg) else new msgQUserToMotor msgQUserToMotor->Add(userControlMsg) if(msgQUserToStatus != nullptr)


msgQUserToStatus->Add(userControlMsg) else new msgQUserToStatus msgQUserToStatus->Add(userControlMsg)

Timing: Issue: input timing Deadline/Freq: Receives userCommand sporadically

Issue: output timing Deadline/Freq: userControlMsg sent sporadically.

userControlMsg sent to all recipients at the same time.

Can only send userControlMsg when in user control mode.

Toggle sent sporadically and at different time than user-

ControlMsg.




Errors: Description: No outgoing message queue Response: Create an outgoing message queue

Description: Invalid userCommand Response: no userControlMsg sent


4.2.6 PROC5


Unique ID: [PROC5]

Name: statusManager()

Description: The “status manager process” receives, stores, and maintains status information from the

sensors and current motor commands. It keeps track and archives the processed mes-

sages with their serial number and a respective time stamps. It sends a sysStatusMsg to

the webpage providing the user feedback on the internal state of the system.

Inputs: Type: Event Mes-

sage

Name: sensorStatusMsg Description: A message whose payload has all the

sensors’ status encoded in the data


Name: autoControlMsg Description: Contains a control command originating from the auto control process

Type: Event Mes-

sage

Name: userControlMsg Description: Contains a control command originating

from the user manually operating system

Outputs: Type: Event Mes-

sage

Name: sysStatusMsg Description: A message whose payload contains in-

formation on the current state of all sen-sors and actuator (motor) activity

Subprocess: Signature: Byte statusByte(void) Description: Retrieves the statusByte data from the sensor-

StatusMsg.

Signature: Byte controlStateByte(void) Description: Retrieves the controlState data from either the auto-

ControlMsg or the userControlMsg.

Signature: void msgSend() Description: Send the message to the appropriate message queue

Algorithm: Byte statusByte(void) If msgQSensorToStatusMgr exists Retrieve statusByte from sensorStatusMsg. Retrieve msgID from sensorStatus. Store statusByte. Store msgID. Call msgQSend.

Byte controlStateByte(void) If msgIncomingQ exists Retrieve controlState from message received (either autoControlMsg or userControlMsg). Retrieve msgID from message received. Store controlStateByte. Store msgID. Call MsgQSend. void msgSend () If error Set eight bit in receiverByte (index 7) equal to 1 (bit eight signifies an Error). Set first through third bits in receiverByte (indices 0, 1, 2) equal to 0. Set fourth bit in receiverByte (index 3) equal to 1 (to signify webPage is a receiver of sysStatusMsg). Load receiverByte into sysStatusMsg. Load statusByte into sysStatusMsg. Load controlStateByte into sysStatusMsg.


Pseudocode: Byte statusByte(void) if(msgQSensorToStatusMgr != nullptr) for(i = 0; i < 8; i++) sensorMsgID += sensorStatusMsg[i] for(i = 8; i < 16; i++) statusByte += sensorStatusMsg[i] sysStatus += sensorID sysStatus += statusByte msgQSend() Byte controlStateByte(void) if(msgQAutoToStatus != nullptr) for(i = 0; i < 8; i++) controlMsgID += autoControlMsg[i] for(i = 8; i < 16; i++) commandByte += autoControlMsg[i] else for(i = 0; i < 8; i++) controlMsgID += userControlMsg[i] for(i = 8; i < 16; i++) commandByte += userControlMsg[i] sysStatus +=controlMsgID sysStatus += commandByte

msgSend () void msgSend() if(error != nullptr) receiverByte[7] = 1 for(i = 0; i < 3; i++)

receiverByte[i] = 0 receiverByte[[3] = 1 for(i = 4; i < 8; i++) receiverByte[i] = 0 sysStatusMsg += receiverByte sysStatusMsg += statusByte sysStatusMsg += controlStateByte msgQWebPage->Add(sysStatusMsg)

Timing: Issue: input timing Deadline/Freq: sensorStatusMsg arrives continuously and periodically.

autoControlMsg and userControlMsg arrive sporadically

and at different times.

Issue: output timing Deadline/Freq: updated sysStatusMsg sent at the end of every execution cycle





Description: Unspecified error Response: Report error to webpage

4.2.7 PROC6


Unique ID: [PROC6]

Name: WebPage()

Description: The startup commands called from the command line in Tornado when the web page is

accessed. Creates all the threads and real-time objects.


Inputs: NA

Outputs: Type: Event Mes-sage

Name: initCompleteMsg Description: A message that sends a message once on initialization once all tasks have been

created.

Subprocess: NA

Algorithm: New task sensorPoll(). New task autoControl(). New task manualControl(). New task motorControl(). New task statusManager(). New message queue from sensorPoll to autoControl. New message queue from sensorPoll to statusManager. New message queue from autoControl to motorControl. New message queue from autoControl to statusManager. New message queue from userControl to motorControl. New message queue from userControl to statusManager. New semaphore toggle (for control mode). autoControl() take toggle semaphore. manualControl() sleep. Start statusManager(). Start sensorPoll(). Start autoControl(). Start motorControl(). Start usercontrol(). Send initCompleteMsg.

Pseudocode: new sensorPoll() new autoControl() new manualControl() new motorControl() new statusManager() new msgQSensorToAuto new msgQSensorToStatus new msgQAutoToMotor new msgQAutoToStatus new msgQUserToMotor new msgQUserToStatus new semaphore(toggle) new autoControl() new manualControl() statusManager()->Start sensorPoll()->Start autoControl()->Start motorControl()->Start userControl()->Start

Timing: Issue: time of execution Deadline/Freq: No more than 10ms

Errors: NA


4.3 System Modes

Figure 2 provides a state chart diagram depicting the possible states in which the system can be.

Figure 2: APE State Chart


Auto Control Mode (Default Mode)

Figure 3 provides a Data Flow Diagram for the software processes involved in the auto control mode.

Figure 3: Data Flow Diagram for the Auto Control Mode


User Control Mode

Figure 4 provides a Data Flow Diagram for the software processes involved in the user control mode.

Figure 4: Data Flow Diagram for the User Control Mode


4.4 Web Interface

4.4.1 Mockup for APE Web Interface Page “home.asp”

Current Control Mode: Manual Control Change Mode REFRESH

Current Operational State:

Status Manual Mode Control

Sensor1 detect

Sensor2 no detect

Sensor3 no detect

Sensor4 no detect

Motor1 active start stop

Motor2 inactive start stop

Scanner home home SCAN POSITION

Pusher home home TRANSITION PLACE

Item Status Tracking

Index Item Serial # State Timestamp

0000 110607001 Detected By S1 1106071115

0001 110607001 Left S1 1106071120

0002 110607001 Detected By S2 1106071125

0003 110607001 Scanned 1106071130

0004 110607001 Left S2 1106071135

0005 110607001 Detected By S3 1106071140

0006 110607001 Left S3 1106071145

0007 110607001 Detected By S4 1106071150

0008 110607001 Left S4 1106071205

0009 110607002 Detected By S1 1106071215

0010 110607002 Left S1 1106071225


…etc.

4.4.2 Description of Mockups

The “home.asp” page provides an interface to the APE for the user via a web browser. The code is a mix

of HTML and ASP code that dynamically generates HTML code at page load time. The control mode

header html code is generated in C code function printControlModeHeader() bound to the ASP function

setUpControlModeHeader(). Function printControlModeHeader() queries the internal database for current

control mode read from the web server database and prints it as html source. Then adds an html button for

toggling the opposite control mode. The status viewer/controller html code is generated in C code func-

tion printStatusViewerController () bound to the ASP function setStatusViewerController (). Function

printStatusViewerController() uses a hard-coded html layout for the system images and replaces the cor-

responding text for current state of sensor S1,S2,S3,S4 as well as acuators Motor1, Motor2, Scanner, and

Pusher read from the web server database. The item status tracker html code is generated in C code func-

tion printStatusTracker () bound to the ASP function setStatusTracker (). Function printStatusTracker ()

uses a hard-coded html table and displays the last ten item status updates in the webserver database as

well as navigation buttons that allow reloading of the page to view past or return to current item status

information. All operations requested via html links will be through the POST or GET variables. This

data is sent by appending them in the link URL you are following upon click using the standard

GET/POST format. Example URL:

“http://137.161.130.51/home.asp?SET_CONTROL=manual&STATUS_PAGE=20”

or in html link code:

<a

href="/home.asp?SET_CONTROL=%nextControlMode%&STATUS_PAGE=%currentStatusPage%">

toggle %nextControlMode% Control</a>


4.4.3 Pseudo Code for APE Web Interface Page “home.asp”

<html>

<head>

<title>APE Web Interface Page (Team Blue)</title>

<META HTTP-EQUIV="REFRESH" CONTENT="1">

<!—- Automatic refresh after 1 second -->

</head>

<body>

<center>

<h1> APE Web Interface</h1>

</center>

<% setUpControlModeHeader(); %>

<!—- ASP to C Code Binded Function in webserver to generate control mode and button -->

<% setStatusViewerController(); %>

<!—- ASP to C Code Binded Function in webserver to generate system status -->

<!—- also adds status buttons in manual control mode -->

<% setStatusTracker(); %>

<!—- ASP to C Code Binded Function in webserver to generate item tracking and buttons -->

</body>

</html>

4.4.4 GoAhead Web Component Function and Member Description

The GoAhead Webserver is an open source software package that is downloaded from GoAhead's web-

site and can be modified with proper credit under use of they're license agreement. This package shall

build VxWorks and run on the arcom box under the realtime environment with an included internal data-

base. We shall add a C file, status.c, to the webserver project which shall define our database handling,

concurrent interface with [PROC5] status manage process and [PROC4] uers control interface, as well as

special html formatting code for user interface viewing and control. To ensure our added source file will

be initialized and run correctly we shall add a call to our function initializeAPESettings(), from status.c,

in main.c of webserver at line 212 in the static int initWebs() function. This will set up our code to run

and initializes the database with our Item_Status table for managing status updates and output.


This section goes into low level design with select sections of pseudo-code.

Database definition:

TableName= Item_Status

Name: Type: Format:

ID unsigned int unique Id, that increments for each add start-

ing at 0

SERIAL_NUM unsigned int MMDDYYSSSS where SSSS is a leading

zeroed 4 digit number starting with 0001

STATUS int Enumerated index value of status

TIMESTAMP unsigned long MMDDYYHHmm format

Along with the status updates we must have global variables that maintain the state of system control

mode, the status of sensors, and the state of the motors.

Global Variables:

int nSensor1State int nSensor2State int nSensor3State int nSensor4State int nMotor1State int nMotor2State int nScannerState int nPusherState int nControlMode StatusMsgQueue msgQueue

Next we shall define the enumeration for mapping status type to its textual representation.

Enumerations:

General enumeration: const int ERROR = -1

For Items Status const int DETECTED_BY_S1 = 0 const int LEFT_S1 = 1 const int DETECTED_BY_S2 = 2 const int SCANNED = 3 const int LEFT_S2 = 4 const int DETECTED_BY_S3 = 5 const int LEFT_S3 = 6 const int DETECTED_BY_S4 = 7 const int LEFT_S4 = 8

For Sensor status: const int NO_DETECT = 10 const int DETECT = 11


For Motors status: const int INACTIVE = 20 const int ACTIVE = 21

For Scanner or Pusher status: const int HOME_POSITION = 30 const int OTHER_POSITION = 31

For Control Modes: const int AUTO_CONTROL = 100 const int MANUAL_CONTROL = 101

Finally to ensure thread safety we create two semaphores for database management(there is not evidence

that the webserver database is thread safe), and global variable/datbase modification.

Semaphores:

SemM queueMutex

//This will be checked/set before and after any read or writes from the message queue SemM dbMutex

//This will be checked/set before and after any read or writes from the global status variables and the da-

tabase

The following are the functions we shall implement in status.c: bool initializeAPESettings()

{

create database tableset

define database column types

register schema with webserver database api

create queue semaphore

create database/global status variable semaphore

register printControlModeHeader() as the C function that binds with ASP function “setUpControlMode-Header”

register printStatusViewerController () as the C function that binds with ASP function “setStatusViewer-Controller”

register printStatusTracker () as the C function that binds with ASP function “setStatusTracker”

} Intializes database and registers ASP to C binding for webpage callbacks.

bool onStatusMsg(StatusMsg& msg)


{

static int nCounter=-1

parse msg data

if sensor, control, or control mode call set function:

setXXXXStatus(nState)

otherwise insert item status data in database

insertStatus(++nCounter,,,,,)

return passOrFail boolean

}

Handles incoming status messages/events.

void printControlModeHeader()

{

webPrint(“<p>Current Control Mode:”)

if getcontrol mode == MANUAL_CONTROL

webPrint(“<em>Manual Control</em>”)

webPrint(“<a

href=\”home.asp?CONTROL_MODE=auto\”>ChangeControl</a>”)

else

webPrint(“<em>Automatic Control</em>”)

webPrint(“<a

href=\”home.asp?CONTROL_MODE=manual\”>ChangeControl</a>”)

webPrint(“</p>”)

}

Outputs HTML table at page load time that corresponds to the current control mode and control to change

it.

void printStatusViewerController()

Outputs HTML table at page load time that corresponds to the current system status and control options in

manual control mode.

void printStatusTracker()

Outputs HTML table at page load time that corresponds to the item status messages recieved.

void processControlButton()

{

get list of GET/POST variables set

depending on which set, construct the corresponding control message


store data in control msg

send control msg

page automatically reloads

}

This processes user input and sends a corresponding message for toggling control modes or manually

controlling a device. (reads variable from GET/POST)

bool pushMsg(StatusMsg& msg)

This will thread safely push a message on the queue

bool popMsg(StatusMsg& msg)

This will thread safely pop a message from the queue

bool insertStatus(const unsigned int& unID,cconst unsigned int& unSerial-Num,const int& unState, const unsigned long& ulTimeStamp)

This will thread safely insert a status message on the database

int getStatusCount()

This will thread safely get the status table row count

bool getStatus(const unsigned int& unID, unsigned int& unSerialNum, int &unState, unsigned long& ulTimeStamp)

This will thread safely get a status message on the database with the specified ID (Id starts from 0 to get-

StatusCount())

void setSensor1State(const int& nState) void setSensor2State(const int& nState) void setSensor3State(const int& nState) void setSensor4State(const int& nState) void setMotor1State(const int& nState) void setMotor2State(const int& nState) void setScannerState(const int& nState) void setPusherState(const int& nState) void setControlMode(const int& nMode)

These will thread safely set the corresponding sensor or control state/mode

int& getSensor1State() int& getSensor2State() int& getSensor3State() int& getSensor4State() int& getMotor1State() int& getMotor2State() int& getScannerState() int& getPusherState() int& getControlMode()

These will thread safely get the corresponding sensor or control state/mode


Appendix A – Data Dictionary

Automatic Production Environment: Data Dictionary

autoControlMsg = Contains an actuator control command originating from system's automatic

control process,

Type: Event Message

motor1Command = Command instructing motor1 to move or stop belt1,

Type: Enumerated value

[forward | backward | stop]

motor2Command = Command instructing motor2 to move or stop belt2,


[forward | backward | stop]

pusherCommand = Command instructing pusher to go extended or home,


[home | extend | stop]

pushExtendSignal = the signal from the pusher extend position switch,


[true | false | error]

pushHomeSignal = the signal from the pusher home position switch,



s1Signal = the signal from line sensor1,


[detect | no detect | error]











scanDownSignal = the signal from the scan down position switch,



scanHomeSignal = the signal from the scan home position switch,



scannerCommand = Command instructing scanner to go to down position or to home position,

Enumerated value

[scan | home | stop]

sensorStatusMsg = A message whose payload has all the sensors’ status encoded in the data,

Type: Event Message

sysStatusMsg = A message whose payload contains information on the current state of all sen-

sors and actuator (motor) activity,

Type: Event Message

toggle = request for releasing control to userControl() or returning control from user-

Control(),

Type: Event Message

userCommand = A user command sent from the webpage,

Type: Event Message

userControlMsg = Contains a control command originating from the user manually operating

system,

Type: Event Message


Appendix B – Requirements Traceability Matrix

Requirements Traceability Matrix

Name BLUE Date 10/8/2007 Version 1.0

Project APE Course SE545 Instructor Kornecki

Entry# Req # Owner Priority Use Case # Use Case

Class/Method/Process/ Design Section

Test Case Edit/Change

1 [SYS_USER1] Griffis webPage

2 [SYS_USER1.1] Griffis webPage








10 [SYS_CNST1] Pfeifer Section 1.1




14 [SYS_CNST5] Pfeifer Deleted

15

[SYS_CNST6]

Pfeifer PROC1, PROC2, PROC3, PROC4,

PROC5

16

[SYS_CNST7]

Pfeifer PROC1, PROC2, PROC3, PROC4, PROC5, PROC6

17 [SYS_CNST8] Pfeifer Deleted





22 [SYS_STRD1] Pfeifer Section 1.1



25 [ASMP1] Griffis Section 1.1





30

[SYS_FUNC1]

Pfeifer sensorPoll, autoControl or userControl, status-Manager, webPage,

motorControl

31

[SYS_FUNC2]


motorControl

32 [SYS_FUNC3] Pfeifer motorControl

33 [SYS_FUNC4] Pfeifer motorControl


34

[SYS_FUNC5]


motorControl

35

[SYS_FUNC6]


motorControl

36

[SYS_FUNC7]


motorControl

37 [SYS_FUNC8] Pfeifer statusManager

38 [SYS_FUNC9] Pfeifer webPage

39

[SYS_FUNC11]


motorControl

40 [INT_SYS1] Griffis webPage

41 [INT_SYS2] Griffis Section 1.2

42

[SYS_CNST11]

Pfeifer sensorPoll, autoControl, userControl, motorCon-

trol

42

[SYS_CNST12]

Pfeifer sensorPoll, autoControl, userControl, motorCon-

trol

43 [HW_CNST1] McGuire Section 1.2

44 [HW_CNST2]

McGuire Deleted

45 [HW_CNST3] McGuire Figure 1

46 [HW_CNST4] McGuire Figure 1

47 [HW_NONF1] McGuire Section 1.2



50 [HW_NONF4] McGuire Figure 1, Section 1.2







57 [HW_FUNC1] McGuire Figure 1, Section 1.2











67 [INT_USER1]

McGuire webPage Griffis 10/08/07

68 [INT_USER1.1]


69 [INT_USER2]


70 [INT_USER2.1]


71 [INT_USER2.1.1]


72 [INT_USER2.2]

McGuire Deleted Griffis 10/08/07

73 [INT_USER2.2.1]


74 [INT_USER2.2.2]


75 [INT_USER2.2.3]


76 [INT_USER2.2.4]


77 [INT_USER2.2.5]


78 [INT_USER2.2.6]


79 [INT_USER2.3]


80 [INT_USER2.4]


81 [INT_USER2.5]


82 [INT_USER2.6]


83 [INT_USER2.7]


84 [INT_USER2.8]


85 [INT_USER2.9]


86 [INT_USER2.10]


87 [INT_USER3]


88 [INT_USER3.1]


89 [INT_USER3.2]


90 [INT_USER3.3]


91 [INT_USER3.4]


92 [INT_USER3.5]


93 [INT_USER3.6]



94 [INT_USER3.7]


95 [INT_USER3.8]


96 [INT_USER3.9]


97 [INT_USER3.10]


98 [INT_COMM1] Griffis Section 1.2

99 [INT_COMM2] Griffis Section 1.2

100 [SW_FUNC1] Griffis PROC1


102 [SW_FUNC2.1] Griffis PROC2




106 [SW_FUNC6]

Griffis autoControl, userCon-trol, webPage

107 [SW_FUNC6.1]

Griffis autoControl, motorCon-trol

108 [SW_FUNC6.1.1] Griffis motorControl

109 [SW_FUNC6.2]

Griffis userControl, motorCon-trol

110 [SW_FUNC6.2.1] Griffis motorControl

111 [SW_FUNC6.3] Griffis autoControl

112 [SW_FUNC6.4] Griffis Section 1.2

113 [SW_PERF1] Griffis Deleted

114 [SW_PERF2] Griffis Deleted

specification & design of real-time systems fa 07 se 545...

Documents