Automated_Test_System_Software_Sample_Task.pdf

Automated Test Equipment Software Exercise

Contents Instructions

Definitions

Deliverables

Grading

Project Organization

Coding Style

Requirements Fulfillment

Documentation

In-Code Documentation

Architecture Document

Questions Regarding Requirements

Project Specifications

Overview

Concept of Execution

User Interface

Client/Server Communication

Server/ECU Communication

Simulated ECU2

Configuration

Results Logging

Error Handling/Logging

Instructions Implement the software as defined in the Project Specifications Section using:

• LabVIEW version 2013 or 2014 as the Integrated Development Environment (IDE)

• Object-Oriented Programming (OOP) as implemented by LabVIEW

• the Actor Framework as part of the framework for the overall architecture

• Author’s name, credentials and employer o What labor category will the author fulfill in the proposal

Definitions Software Unit – A Software Unit is any arbitrary but logical functional grouping of code which could be a Class or Class Family, Group of VIs, etc. Each module or high-level function should be considered a Software Unit.

Client/Server – Two separate computer systems communicating through TCP where one is the user facing Client and one is the vehicle facing Server.

Deliverables For the purpose of this exercise you are required to design an architecture that covers the requirements outlined in the Project Specifications Section. Your architecture should include:

• Project Organization and Hierarchy

• User Interfaces

• Modularization and Application Programming Interface (API) for the modules

• Communication between modules/components

• Top-Level Loops and Design Patterns

• Error Handling/Logging

• Results Logging

Assume that the lower level algorithms, protocol messaging, states, and functions will be implemented by secondary developers and do not need to be implemented as part of this exercise. However, enough instruction should be given to indicate where a requirement will be fulfilled and should be located in the most appropriate place on the block diagrams of the source code.

The delivered package must include:

• All Source Code o Developed Code o Third-Party/Add-on Toolkits or Packages Used that are not part of the regular LabVIEW

Installation

• High Level Architecture Document o Defines Software Units o Defines Interfaces between Software Units

Grading Each bullet in the grading section is given 0, 3, or 5 points

0 = Requirement not fulfilled 3 = Requirement partially fulfilled 5 = Requirement fully fulfilled

“Not fulfilled” means the requirement was not addressed, and/or coding style, organization, and documentation is insufficient to allow for readability, maintainability, or exensibility of the code or supporting documentation.

“Partially fulfilled” means the requirement was not complete in that existence of a significant weakness or combination of weaknesses would likely cause degraded performance.

“Fully fulfilled” means that the requirement is covered to the depth described in the requirements statement, and the code and supporting documentation is readable, maintainable, and extensible.

The points given for each bullet is summed by section. The weight is then applied to each section (points * weight).

The weighted scores are then summed to give the final score.

The grading breakdown will be as follows:

Table 1 - Grading Breakdown

Category Possible Points Weight Possible Score Project Organization 20 5 100 Coding Style 15 5 75 Requirements Fulfillment 80 4 320 Documentation 25 6 150 Final Score 645

Project Organization Use of the Project Explorer is required. Organization on disk and in the Project Explorer does not need to match but both must be logical such that:

• Main VIs are easily located (5 points possible)

• Functionality is grouped/logically located together (5 points possible)

• Documentation is easily located (5 points possible)

• Locations are defined for SubVIs that will be created later by developers (5 points possible)

Coding Style Code should be readable. Refer to National Instruments’ LabVIEW Style Guide for general guidelines.

• Front Panel Style (5 points possible)

“Front panels must be well-organized and easy to use because users see the front panel first when working with a VI. When designing a front panel, keep in mind two types of users, the end user and the developer.

End users work with user interface VIs, which have front panels that only the end user sees, and developers work with subVIs, which have front panels that only developers see.” (National Instruments LabVIEW Development Guidelines, Chapter 6: LabVIEW Style Guide).

• Block Diagram Style (5 points possible)

“The block diagram is the primary way for others to understand how a VI works, therefore it is often worth the effort to follow a few simple steps to make block diagrams more organized and easier to read.

“Style is as important on the block diagram of the VI as on the front panel. Users may not see the block diagram, but other developers do. A well-planned, consistent block diagram is easier to understand and modify.” (National Instruments LabVIEW Development Guidelines, Chapter 6: LabVIEW Style Guide).

• Icon and Connector Pane Style (5 points possible)

“Using good style techniques when creating the icons and connector panes for VIs can greatly benefit users of those VIs.” (National Instruments LabVIEW Development Guidelines, Chapter 6: LabVIEW Style Guide).

Requirements Fulfillment In order to demonstrate requirements fulfillment grading is based on two parts:

1. Requirement IDs covered (5 points per requirement sub-section; 40 points possible)

2. Associated code fulfills the requirement given (5 points per requirement sub-section; 40 points possible)

The requirement sub-sections are listed below in the Project Specifications Section and are as follows:

1. Concept of Execution

2. User Interface

3. Client/Server Communication

4. Server/ECU Communication

5. Simulated ECU2

6. Configuration

7. Results Logging

8. Error Handling/Logging.

To determine where the requirement is covered, each Requirement Statement in the Project Specifications Section is given an ID. (For Example, if there is a User Interface (UI) requirement to have a specific button, the requirement ID could be UI3, meaning UI requirement number 3.) Use these IDs in the Bookmarks in the LabVIEW IDE by preceding the ID with the hash tag (#). As in the previous example the Bookmark Tag would then be #UI3.

Bookmarks can only be found by the Bookmark Manager if they exist on the block diagram. Therefore, after the ID type a space or carriage return and then include a description of where and how the requirement is fulfilled.

Documentation

In-Code Documentation Enough in-code documentation should be included to help a secondary developer.

• Every VI should have a description of what the VI does. (5 points possible)

• Descriptions for Controls/Indicators are not necessary except when helpful to describe interfaces. (5 points possible)

• Include Documentation on block diagram as required to communicate architecture and methodology to secondary developer. (5 points possible)

• Documentation of SubVIs that are internal to the Actor Framework are not necessary. However, explanation of the top level Actor Framework VIs may be added as necessary to give direction to the secondary developer. (5 points possible)

Architecture Document This is not to replace in-code documentation. This document should define functional groups as Software Units and describe the interfaces between these Software Units. (5 points possible)

Questions Regarding Requirements Questions will not be answered regarding the requirements in this exercise. If a requirement is unclear, make an assumption as to the interpretation of the requirement, document the assumption, and continue with the exercise.

Project Specifications

Overview A new piece of Automated Test Equipment (ATE) is being developed to troubleshoot avionics and load flight software onto a military aircraft. The software for this would include functions to monitor bus traffic, issue commands to various Embedded Control Units (ECUs), to perform internal Built-In Tests (BITs), and upload Embedded Control Programs (ECPs) onto the ECUs.

The software is required to operate on an ATE where the User Interface (UI) is resident on one computer (Client) and the testing hardware is located on separate control computer (Server) which is connected through TCP. The busses used to communicate to the ECUs are a Mil/Aerospace Standard Protocol (i.e. 1553), Ethernet, and Serial.

All three communication busses should be represented but actual implementation of the protocol is not required for this exercise.

It is also anticipated that ECU2 will have limited availability for testing. A simulation of ECU2 will need to be created when ECU2 is not present.

Vehicle

Server Client

UI Server Processes

ECU1

ECU2 HW

Ethernet

ECU2 Sim Ethernet

ECU3

Serial

Project Boundary

Figure 1 - ATE Overview – Project Boundary

1. Concept of Execution CE1. The user will start the Client which should initiate the Server.

CE2. When connected the user can choose to:

CE2A. Monitor Bus Traffic CE2B. Perform BITs CE2C. Load ECPs

CE3. Commands are sent to the server to initiate functions.

CE4. Responses are returned to update UI or show completed operations.

CE5. Results will be displayed to user and logged to file.

CE6. User can exit program or begin new troubleshooting session.

2. User Interface UI1. The client must contain all of the UI.

UI2. Five UI Screens shall be created and include:

UI2A. Splash Screen

UI2B. Main Menu UI2C. Monitor Busses UI2D. Initiate BITs UI2E. Load ECPs UI2F. Display Results UI3. The Splash Screen shall:

UI3A. Show on startup UI3B. Make and show connection to Server UI3C. Navigate to Main Menu after successful connection UI3D. If connection is not made, prompts user to try again or quit

UI4. Main Menu Screen shall:

UI4A. Have buttons to launch “Monitor Busses”, “Initiate BITs”, and “Load ECP”

UI4A1. Clicking Button shall launch correct Screen UI4B. Have button to start new logging session UI4C. Have button to exit Client and close Server

UI5. Monitor Bus Screen shall:

UI5A. Have selection between busses: “1553”, “Ethernet”, and “Serial” UI5B. Have table where results will be displayed UI5C. Have buttons to “Start Monitoring” and to “Stop Monitoring” UI5D. Have “Close” button to close monitoring and return to Main Menu

UI6. Load ECP Screen shall:

UI6A. Have selection between ECUs: “ECU1”, “ECU2”, etc.

UI6B. Have “Start Load” button to begin Load UI6C. Have progress displayed as load occurs UI6D. Show status of load: “In Progress”, “Completed – Successful”, or “Failed” UI6E. Have “Close” button to close ECP loads and return to Main Menu

UI7. Display Results Screen shall:

UI7A. Have selection between result status: “Passed”, “Failed”, and “All” UI7B. Have “Results” displayed in a logical manner (table, tree, etc.)

UI7C. Have “Load Previous Results” button UI7D. Have “Close” button to results and return to Main Menu

3. Client/Server Communication CS1. Communication between the Client and Server shall be TCP.

CS2. Communication shall be abstracted and an API used to send Commands (Client to Server) and receive Responses (Server to Client).

4. Server/ECU Communication SC1. Have separate methods for communication for each bus:

SC1A. 1553 API

SC1B. Ethernet API SC1C. Serial API

SC2. In this exercise there is only one ECU per bus. However, the communication needs to be architected for addition of multiple ECUs per bus.

SC3. Communication protocols for 1553 and Serial Busses do not need to be implemented but documentation shall exist to explain where messaging should be implemented.

SC4. Simulated Ethernet communication shall be implemented when communicating with the Simulated ECU2

SC4A. Switching between an actual and a simulated ECU2 shall be configurable, See Req.CF1 and CF1A.

5. Simulated ECU2 SIM1. The Simulated ECU2 shall respond according to the following table:

Table 2 - Messaging for Simulated ECU2

Message Received by Simulated ECU2

Response Sent by Simulated ECU2

“Start Monitor” “SIM: Monitor Started” “Stop Monitor” “SIM: Monitor Stopped” “Start BIT” “SIM: Starting BIT”

[Wait 5 Seconds] “SIM: BIT Passed”

“ECP Load” “SIM: Loading ECP” [Wait 5 Seconds] “SIM: Load Complete”

SIM2. The Simulated ECU2’s Ethernet communications shall be “localhost” while the actual will be set by configuration, See Req.CF1 and CF1A.

6. Configuration CF1. Configuration that is changeable after deployment of the application shall be stored in a Human readable/changeable format.

CF1A. One entry in the configuration file shall be if ECU2 is “Present” or “Simulated”

CF1B. Necessary assignments for an actual ECU2’s Ethernet communication shall be set in the configuration file.

CF1B1. The entries for “Port” and “Address” shall be present in the configuration file.

CF2. Configuration that is not changeable after deployment of the application but would be changeable between released versions shall be stored in an MS Access database.

Note: Creation of the database is not required but top-level VIs should be created where database queries would occur.

7. Results Logging RL1. Test result shall be logged to a file.

RL2. Previous results shall be loaded and viewable in the Results Screen.

8. Error Handling/Logging EH1. Errors shall be categorized into three classes by severity: “Critical”, “Severe”, “Warning”

EH2. In all cases the error shall be logged to file with time stamp EH3. Critical Errors shall prompt the user of the error and execute a safe shutdown.

EH4. Severe Errors shall prompt the user but shall allow for continued operation of the program EH5. Warning Errors shall log the error to file only and shall allow for continued operation of the program