Automatic Production Environment: Project Description

1. Automatic Production Environment:Project 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 Cfunction calls • User Control • Standard HTTP GET variables encoded in links • processed by GoForms:GoAhead’s 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?MODE=0” • 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?