DOC

Software Development Plan

By Scott Harris,2014-04-15 15:21
9 views 0
22nd July 2005, High-level Design (System Architecture), Changsun Song. TBD, 1st Iteration Detailed Design (x 4), MBARS Team

    CMU 17-614 Engineering Software Intensive Systems Summer 2005

     MBARS Project Team Name: MACNAV Software Development Plan Due: 7/XX/05

     for MCNAV001Lunar Robot

    MCNAV Software Development Plan

    (SDP)

    Team MCNAV

    Carnegie Mellon University SDP Rev: 0.3

    17614 Engineering Software Intensive Systems Carnegie Mellon University Summer ‘05

    DUE DATE: 15 July, 2005

    TITLE: DARPA Lunar Grand Challenge 2005 MBARS

    AUTHOR(s): Team MCNAV DATE: 16 July, 2005

    This document describes the plan for the development of the software ABSTRACT:

    required for the MCNAV system, a competitor in the DARPA Lunar Grand

    Challenge 2005. The plan focuses on use/maintenance of COTS software,

    development and integration of new software, and maintenance of software

    after launch.

    Revision History

    Rev Date Control No. Author Change Comment

    *Create* the template, Guislaine, Gurmit and V0 07-05-2005 1 O. Sanchez Gary’s comments incorporated

    *Modify* the organisation, and the WBS

    V1 07-11-2005 1 O. Sanchez with Sam’s comments

    *Complete* section 8, 9 and 10

    *Add* Software packages & acquisition

    O. Sanchez, C. strategies Incomplete) V2 07-15-2005 1 Wang, G. Hernandez *Add* Pre-launch maintenance strategy

    *Remove* Estimates + Reporting sections

    *Added* Iterations contents V3 07-16-2005 1 O. Sanchez, C. Wang *Added” post-launch maintenance strategy

49829288.doc 1 of 7 Last Updated: 4/15/2010 @ 3:20 PM

    CMU 17-614 Engineering Software Intensive Systems Summer 2005

     MBARS Project Team Name: MACNAV Software Development Plan Due: 7/XX/05

     for MCNAV001Lunar Robot

1. Document Overview

    1.1 Purpose

The Software Development Plan (SDP) describes a developer's plans for conducting a software

    development effort. It includes new development, modification, reuse, reengineering,

    maintenance, and all other activities resulting in software products.

This document provides the acquirer insight into, and a tool for monitoring, the processes to be

    followed for software development, the methods to be used, the approach to be followed for each

    activity, and project schedules, organization, and resources.

1.2 Definitions

    Table 1 MBARS Terms and Acronyms

    Acronym Translation Definition

    DARPA Defense Advanced Research Projects Agency MBARS Moon Based Autonomous Robot System MCNAV Moon CircumNavigating Autonomous Vehicle 1.3 References

    Table 2 References for Operational Concept Document

    ID Reference

    1. Lunar Grand Challenge Requirements 06/12/05

    2.

    2. Software Development High-level Schedule

    Date Deliverable Responsible nd22 July 2005 High-level Design (System Architecture) Changsun Song stTBD 1 Iteration Detailed Design (x 4) MBARS Team stTBD 1 Iteration Unit Testing (x 4) MBARS Team stTBD 1 Iteration System Integration & Testing MBARS Team ndTBD 2 Iteration Detailed Design (x 4) MBARS Team ndTBD 2 Iteration Unit Testing (x 4) MBARS Team ndTBD 2 Iteration System Integration & Testing MBARS Team rdTBD 3 Iteration Detailed Design (x 4) MBARS Team rdTBD 3 Iteration Unit Testing (x 4) MBARS Team rdTBD 3 Iteration System Integration & Testing MBARS Team thTBD 4 Iteration Detailed Design (x 4) MBARS Team thTBD 4 Iteration Unit Testing (x 4) MBARS Team thTBD 4 Iteration System Integration & Testing MBARS Team TBD Bug-fixing MBARS Team TBD Final System Integration & Testing MBARS Team TBD Qualification Test MBARS Team 49829288.doc 2 of 7 Last Updated: 4/15/2010 @ 3:20 PM

    CMU 17-614 Engineering Software Intensive Systems Summer 2005

     MBARS Project Team Name: MACNAV Software Development Plan Due: 7/XX/05

     for MCNAV001Lunar Robot

    TBD Launch & final deployment (race day) MBARS Team

Date Deliverable Responsible 3. Software Development Approach

3.1 Lifecycle

An iterative incremental development approach is adopted.

    Each iteration is composed of a complete development lifecycle; it includes detailed design, unit

    and integration testing. At each iteration the capabilities are increased. The final iteration (the

    forth) consists of all system capabilities.

3.2 Integration Approach

Each development iteration consists of an integration activity. All the sib-systems are integrated

    and tested to guarantee no final integration is required. The integration is therefore incrementally

    performed. Before each integration is performed all sub-systems are unit tested to reduce the

    probability of integration problems due to internal subsystems defects.

    4. Work Breakdown Structure (WBS)

WBS element Description

System Definition ? System Requirements

    Software Requirements ? System Architecture

    ? Reliability Analysis

    ? Software Development Plan

    ? System Test Plan

Requirement Change ? Monitor changes to requirements (from both directions:

    Management customer and development feasibility)

    ? Maintenance of the requirements traceability

Software Project ? Schedule management

    Management ? Resources (staff and software) management

    ? Testing management

49829288.doc 3 of 7 Last Updated: 4/15/2010 @ 3:20 PM

    CMU 17-614 Engineering Software Intensive Systems Summer 2005

     MBARS Project Team Name: MACNAV Software Development Plan Due: 7/XX/05

     for MCNAV001Lunar Robot

     st1 Iteration Basic ? REQ-MB-1 the mobility/locomotion shall be capable of

    Capabilities changing the direction during the travel.

    ? REQ-PG-1 The power system shall supply necessary WBS element Description

    electrical power to maintain vehicle operation for the duration

    of the race

    ? REQ-PG-4 The power system shall supply at least 773.1

    watts electricity as maximum peak power.

    (773.1 watts is estimated refer to technical paper.doc)

    ? REQ-ES-1 The Environment Sensing (ES) system shall be

    capable of perceiving the surrounding environment in terms

    terrain elevation and obstacle detection

    ? REQ-ES-2 The ES system shall provide appropriate terrain

    elevation and obstacle detection information to the vehicle

    processing subsystem for qualifying the pre-planned route.

    ? REQ-CPU-1 The processing system shall monitor and

    control power distribution to guarantee fail-safe delivery of

    essential power to mission critical subsystem

     nd2 Iteration Standard ? REQ-MB-2 the mobility/locomotion shall be capable of

    (isolated) Capabilities moving at the maximum speed of 12 mph.

    ? REQ-MB-3 the mobility/locomotion shall be capable of

    climbing a slope of 45 degrees at maximum.

    ? REQ-PG-2 The power system shall supply necessary

    thermal power to maintain vehicle internal ambient

    temperature for the duration of the race

    ? REQ-PG-3 The power system shall perceive to run out of

    fuel and shift to power-saving mode, in order to extend the

    distance covered in a given fuel.

     rd3 Iteration Advanced ? Mobility/locomotion integration with Power Distribution

    (integrated) Capabilities Management

    ? REQ-PG-5 The power system shall detect a leakage of

    power such as inactivated subsystems or stopped subsystems

    and prevent the waste of power.

    ? REQ-ES-3 The ES system shall be able to function within

    lunar temperature ranges

    ? REQ-ES-4 The ES system shall be able to function within

    high lunar radiation environment

    ? REQ-ES-5 The ES system shall be capable of sensing

    lunar environmental conditions up to 50 meters ahead of the

    vehicle

    ? REQ-CPU-2 the processing system shall communicate

    with all other subsystems.

     th4 Iteration Final ? Integrate all subsystems to achieve all system capabilities

    49829288.doc 4 of 7 Last Updated: 4/15/2010 @ 3:20 PM

CMU 17-614 Engineering Software Intensive Systems Summer 2005

     MBARS Project

    Team Name: MACNAV Software Development Plan Due: 7/XX/05

     for MCNAV001Lunar Robot

Integration

    Final System Integration & ? Simulation of the qualification test Testing WBS element Description

Release & Deployment ? Qualification Test

    ? Launch & final deployment (race day)

5. Software Development Critical Dependencies

    Item Expected delivery date at the Name of the person

    latest responsible for the item Hardware: XXX XXX XXX TBC

6. Software Needs and Acquisition Strategy

Power Sub-system

? Power Distribution Controller

    This has to be developed in house as no COTS alternative is available.

    ? Ambient (Temperature) Controller

    The ambient controller is available as COTS from

    http://www.watlow.com/products/software/watconnect.cfm ? Emergency (STOP) Manager

    This has to be developed in house as no COTS alternative available.

Navigation Sub-system

? Map Data Repository

     Re-use CMU Read Team packages & algorithms

    ? Path Calculation Package

     Re-use CMU Read Team packages & algorithms

    ? Real-time Path Calculation Package

     Re-use CMU Read Team packages & algorithms

    ? Obstacle Detection Package

     Re-use CMU Read Team packages & algorithms

Sensing Sub-system

49829288.doc 5 of 7 Last Updated: 4/15/2010 @ 3:20 PM

    CMU 17-614 Engineering Software Intensive Systems Summer 2005

     MBARS Project Team Name: MACNAV Software Development Plan Due: 7/XX/05

     for MCNAV001Lunar Robot

? TBD

Mobility/locomotion Sub-system

? Direction Controller and its interface to Wheel Motor Interface

     Acquisition strategy: TBD

? Velocity Controller and its interface to Brake Interface, Direction Controller and its interface

     Acquisition strategy: TBD

? Power Constraints Manager and its interface to Power distribution controller.

     Acquisition strategy: TBD

7. Software Development Team Organisation

    Team / Role Responsibilities

    Customer representative ? Express needs

    ? Approve requirements

    ? Accept product

    System Configuration Control Board (CCB) ? Approve SW system baselines

    ? Manage changes to software system

    baselines

    ? Authorize the release of products from the

    software baseline library Power Management Sub-team ? Identify (elicit and gather) software

    requirements for the subsystem

    ? Develop/acquire software components for

    the subsystem

    ? Accept software components (via unit or

    acceptance testing) for the subsystem Mobility Control Sub-team (as above but for different sub-system) Environment Sensing Sub-team (as above but for different sub-system) Navigation Sub-team (as above but for different sub-system) System Integration & Testing Sub-team ? Identify and conduct integration activities

    ? Define integration testing strategies

    ? Conduct integration testing activities

    ? Release software products QA ? Review (this plan and other major

    deliverables)

    ? Do project audits where indicated SCM Sub-team ? Perform SCM baseline audits as identified

    ? Provide SCM support to the project

49829288.doc 6 of 7 Last Updated: 4/15/2010 @ 3:20 PM

CMU 17-614 Engineering Software Intensive Systems Summer 2005

     MBARS Project

    Team Name: MACNAV Software Development Plan Due: 7/XX/05

     for MCNAV001Lunar Robot

8. Software Maintenance

8.1 Maintenance pre-launch

In order to support the software changes required pre-launch, the system will offer the following

    features:

? All software components can be updated from an external source (An Ethernet connection)

? All software packages will offer auto-safety-check mechanisms. These validation

    mechanisms will validate hardware and other preconditions required for the software package to

    perform properly.

? A readiness check test-ware is also loaded together with the software package in order to

    validate the new version of the software and avoid regression of the basic and critical capabilities

    of the system. (See Test Plan for further details)

8.2 Maintenance post launch

Will we have access to the vehicle?? (TBC)

The only maintenance possible actions after launch will be self-performed by the vehicle. This as

    the system main requirement asks for the vehicle to be totally autonomous and no

    communication is allowed from the exterior.

If the system detects a fault, it will perform the following self-maintenance actions:

    - It will go to a safe state: A safe state is defined as a state on which the vehicle stops

    and reboot all the software systems to an initial state. (data gathered is kept intact

    though)

    - If the system cannot reboot again or the defect is reproduced, the system would try

    discarding any data gathered and come back to the initial state of the system (before

    the beginning of the race and therefore loosing any gathered information).

    The vehicle would certainly identify the new starting point though.

    - The system can also shutdown sub-systems and start up backup sub-systems if needed.

    49829288.doc 7 of 7 Last Updated: 4/15/2010 @ 3:20 PM

Report this document

For any questions or suggestions please email
cust-service@docsford.com