Automatic Production Environment: Project Description

1
Automatic Production EnvironmentProject
Description

• FA_07_SE_545
• Team Blue
• 12/12/2007

2
Overview

• Introduction
• Team Organization
• Methodology
• Lessons Learned

3

• Introduction

4
Description Automatic Production Environment

• Meant to simulate an industry control system
• Simulates operation of airport luggage conveyor
  belt system with a security scanning machine
• Electromechanically driven conveyor belt system
  built out of small generic-use modeling blocks

5
Description

• Motors and sensors wired to an onboard embedded
  interface system
• Communicates over a serial cable with the
  embedded interface system
• Bootable software image downloaded to the Arcom
  box developed, tested, and debugged in the
  Tornado IDE

6
Purpose

• Perform a well organized, group-based effort
• More of a project focused effort, than a
  product focused effort
• Create a successfully working product
• More importantly, learn from the project
• Implement and experience a real-time oriented
  software development lifecycle
• well-documented progression
• Waterfall software development lifecycle

7
Scope

• Six software engineering graduate students
• Three month period
• Total effort for the project was 449.75
• Average 74.96 hours/person, /- 25.57 hrs

8

• Team Organization

9
Stakeholders

• Sponsor Dr. Andrew J. Kornecki, Embry-Riddle
  Aeronautical University
• Members of TEAM BLUE
• Christopher Griffis (Team Lead,
  Planning/Requirements Lead )
• Steve Harvey (Webserver Coding Lead)
• Leo Matos (Quality Lead)
• Jason McGuire (Hardware Lead)
• Sean Pfeifer (VxWorks Coding Lead)
• Caylyne Shelton (Design Lead)

10
Team Roles

• Team Lead, Planning/Requirements Lead
  (Christopher Griffis)
• Maintains process and team discipline,
  facilitates team meetings and keeps record of
  meeting times
• Guide preparation of software development plan
• Guide analysis and preparation of the
  requirements document
• Ensure deliverables are complete, punctual, and
  top quality
• VxWorks Coding Lead (Sean Pfeifer)
• Responsible for all coding of the VxWorks
  real-time control aspects
• Use the SDS as a basis for his code
• Design Lead (Caylyne Shelton)
• Develop a high/low level design for the
  development
• Lead the effort to produce the SDS

11
Team Roles

• Webserver Coding Lead (Steve Harvey)
• Responsible for all coding of the webserver
  aspects
• use the SDS as a basis for his code
• Quality Lead (Leonardo Matos)
• maintains the team timelogs and TSP data
• prepare the test plan and coordinate the testing
  phases
• Hardware Lead (Jason McGuire)
• responsible for ensuring that the hardware
  equipment operational
• assist in the coding of the webserver and VxWorks
  integration

12

• Methodology

13
Development Environment

• APE model
• ROBO interface
• Arcom Box
• VxWorks operating system
• GoAhead Webserver
• Tornado IDE

14
Development Process

• Waterfall software development lifecycle
• Modified Team Software Process
• standardized time logs
• meeting records
• Configuration management policies
• Efficient team interaction
• consistent document format
• Blackboard collaboration tool

15
Planning

• Loosely follows IEEE Std. 1058-1998
• Project summary
• Project purpose
• Document purpose
• Stakeholders
• Scope
• Objectives
• System high level requirements
• Project organization
• Project deliverables
• Team role responsibilities
• Available resources
• Risk management plan
• Configuration management plan and quality
  assurance plan

16
Requirements

• Loosely follows IEEE std. 830-1998
• Project purpose, system overview scope, and
  document overview
• Product perspective
• Models and interface description
• Product functions
• User characteristics
• Assumptions
• Specific requirements
• System
• Hardware
• Software
• Interface

17
Requirements Analysis

• Sequence diagrams
• Entity-relationship diagram
• State charts
• Data flow diagrams
• Process specifications
• Scenarios
• Use Cases

18
Architecture and Design

• Loosely follows IEEE std 1016-1998
• Architectural components
• Mechanistic design aspects
• System states
• Entity relationships
• Detailed design aspects
• Functional process design specifications
• System modes
• Web interface design

19
Architecture and Design

• Process design specifications
• Name and description
• Inputs and outputs
• Main algorithm
• Pseudocode
• Timing behavior
• Error states

20
Architecture and Design

• Two modes automatic mode and user control mode
• Automatic mode behaviors declared in the
  requirements
• User control mode allows the user direct control
  over each motor
• Web interface used for user control mode

21
Architecture and Design

• Controllable through a web interface
• SDD has design mockups
• Descriptions and pseudocode

22
Architecture and Design

• Webserver, sensing functions, and motor actuating
  functions in separate modules
• Higher cohesion
• Lower coupling between modules
• Multiple threads
• Sensor polling
• Motor actuation
• Webserver interaction
• Had message queues in design
• Communication synchronization issues
• Switched to semaphore-protected shared data model
  (global vars)
• Watchdogs ensure timeouts are enforced

23
Coding process

• Created proof of concept established
• Communicating to the ROBO unit
• Established initial working design outlined in
  SDD
• Scrapped prototype design by reused components
• Developed and integrated web server components
• Numerous issues encountered discussed later
• Final integration testing
• Testing performed iteratively at all stages of
  development

24
Code size and modules (1)

• Code counting standard
• Used LocMetrics tool
• Blank lines and comment lines not included
• Total LOC
• Total (Raw) 1,579
• SLOC Executable 1,056
• SLOC Logical 603
• McCabe complexity 110
• File count 7

25
Code size and modules (2)
26
Code size and modules (3)

• Modules
• apeConstants.h
• Global constant values used in APE system
• apeGlobals.h
• Global variables shared across system
• apeMotorControl.h
• Header file for shared motor control functions
• apeMotorControl.c
• Definition file for all motor and sensor control
  functions
• apeSystemControl.c
• Definition file system communications and control
  functions

27
User Interface and Control Components

• The user display and control interface were
  handled by the GoAhead Webserver Version 2.1.8
• Layout and Display
• combination of Embedded Javascript and ASP binded
  to C function calls
• User Control
• Standard HTTP GET variables encoded in links
• processed by GoForms GoAheads in-memory CGI
  processor called GoForms

28
User Display Layout and Design

• home.asp main webpage
• HTML, ASP, Javascript
• Compiled into webrom.c and added to our VxWorks
  build project (using GoAhead included rom
  compiler)
• Embedded auto-refresh to display current system
  state
• Simple layout for ease of reading and control
• Color coded states for contrast
• Dynamic layout depending on control mode from ASP
  to C bound function at load time

29
Backend and System Control via Web

• GoForms read GET variables
• Ex http///goForm/control?MODE0
• Variables trigger thread safe control calls to
  APE control
• Simalarly thread safe APE system state calls were
  fed to webserver back end variables used in
  content of interface page
• Sensor states allowed tracking of objects in
  internal web database that updated webpage
  dynamically

30
Issues encountered (1)

• Establishing communications to ROBO unit via
  Arcom GX-1
• Spent 16 hours attempting to open the Arcom GX-1
  serial port to communicate with the ROBO unit.
• Source of the problems was a single flag value
  set when opening the serial port
• No documentation on the web indicating this value
  acquired from Dr. Kornecki

31
Issues encountered (2)

• GoAhead Web server
• 45 hours spent between 3 people attempting to
  create bootable image with web server software
  included.
• Arcom GX-1 would acquire the image from the FTP
  server but reboot every time software execution
  began
• Problem fixed but not fully understood at this
  point bootable image apparently needs to be a
  certain size or Web ROMs need to be included
• Documentation very limited

32
Language considerations

• C language used for development
• Functional language with no OO capabilities
• Coding style must be carefully planned and a
  adhered to prevent spaghetti code
• Syntax archaic compared to modern languages such
  as C or Java
• Code maintenance could be tedious

33
Testing

• Loosely follows IEEE std. 829-1998
• Test plan creation
• Stakeholders, scope, overview, software risk
  issues
• Features to be tested
• Pass/fail criteria, entry and exit criteria
• Test cases are scripts parallel use cases
  identified in requirements
• Requirements traceability matrix confirms the
  testing coverage
• Identifies which test cases cover which
  requirements
• Project testing
• Each test case is performed
• Deviation from expected behavior is recorded

34
Postmortem

• Updating the SDP
• Compiling the team effort time logs
• Complete listing of all meeting records
• User manual
• Project summary
• Html document for a web viewing
• Code counted, analyzed for complexity
• Presentation

35

• Lessons Learned

36
Lessons Learned (I)

• Prototyping is invaluable it helped to get rid
  of a lot of low-level issues and basic
  functionality just don't use the prototype as a
  product.
• The design document was very helpful, and drove
  the development, but parts were identified as
  being too much overhead - doing a quick throwaway
  prototype of the design may be useful.
• Technical issues can use up too much time - try
  to identify these large blocking ones in the
  beginning of the project.
• Pair coding was very valuable, especially when
  there are parts that need to be integrated.

37
Lessons Learned (II)

• Integration can be flawless, provided the
  interfaces are agreed upon and created ahead of
  time!
• Team meet notes are good for documenting
  assumptions and thoughts for later follow up.
  This was essential during the requirements phase
  when discussing the system behavior and dynamics
  of operation.
• Webserver is has a mysterious and unresolved
  idiosyncrasy requiring that the image size be of
  a certain size to work correctly.
• Timing issues associated with real-time software
  development can result in unexpected behavior
  that are hard to debug if not designed for
  appropriately.

38

• Questions?