1 / 38

Automatic Production Environment: Project Description

Automatic Production Environment: Project Description. FA_07_SE_545 Team Blue 12/12/2007. Overview. Introduction Team Organization Methodology Lessons Learned . Introduction. Description: Automatic Production Environment. Meant to simulate an industry control system

juliet
Download Presentation

Automatic Production Environment: Project Description

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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?

More Related