Mosp spring 2011

Team HandSimDroid Anar Huseynov

Ishwinder Singh

Justin Killian

Peter Foldes

Agenda

• Project Overview

• Process

• Requirements

• Risk Management

• System Architecture

• Going Forward

• Accomplishments

• Questions?

2

Agenda


• Process

• Requirements

• Risk Management


• Going Forward

• Accomplishments

• Questions?

3

Team HandSimDriod

4

Team Lead Process/Quality Manager

Development/ Support Manager

Planning Manager

Mentors

TSP Coach

Clients

Context

• Bosch Research & Technology Center (Client)

• Bosch uses an open-source tool called Ptolemy to model and simulate embedded software

• Our project is to create an Android application that can run simulations of Ptolemy models on handheld devices.

5

Ptolemy Desktop Application

Model

Output

6

Project Goals

7

• Show simulations running on the handheld

• Enable UI customization by model and per user

• Create demonstrations that showcase usefulness of functionality to engineers

Business Drivers

• Act as a proof of concept for ASCET tool

▫ Inspire innovation at Bosch

• Improve operations & reduce cost of calibration

▫ Running simulation on the handheld on the go

▫ Customize UI for different purposes & users

• Freely extend open source software

8

Agenda


• Process

• Requirements

• Risk Management


• Going Forward

• Accomplishments

• Questions?

9

TSP Process

Team Software Process

• Why we chose it?

• Is it working for us?

Very organized process with specific roles

Helps us collect lot of data that can be very useful

We don’t know how to interpret everything in the tool

Data is synchronized only once a week

11

Team Software Process Cont.

12

0

20

4

0

60

8

0

100

1/19

/20

11

1/2

6/2

011

2/2

/20

11

2/9

/20

11

2/1

6/2

011

2/2

3/2

011

3/2

/20

11

Earned Value

Ideal EV

Actual EV

Long Term Plan

13

Milestone

Sep. Oct. Nov. Dec.

2010 Fall (732 hours) 2011 Spring (720 hours)

Jan. Feb. March April

2011 Summer (2304 hours)

May June July Aug.

EOSP

SOW

SRE

Planning

High level Design

Detailed Design Testing

EOSP EOSP MOSP

SRS

Proposals

Requirements

Design

QAW

Planning

Implementation

User Guide

Tool Setup

Design Proposal

TSP Training

DONE

TODO

Experiments

• Ptolemy on Android • UI Layout Tool

• Notional Architecture • Experiment 1 • Experiment 2

• Contextual design • Use cases • Paper prototypes

• Communication • UI toolkits • Token overhead • Sensor throughput limits

Team Software Process Cont.

14

43%

24%

9%

7%

6%

3% 3%

2% 2% 1%

Effort by Assembly

MEETING

ARCHITECTURE

MOSP

SRS

TRAINING

MISC

PLANNING

DATA

SYSTEM

PROPOSAL

Agenda


• Process

• Requirements

• Risk Management


• Going Forward

• Accomplishments

• Questions?

15

High Priority, 30 Medium Priority,

25

Low Priority, 5

High Priority

Medium Priority

Low Priority

Priority Requirement Document

16

Requirements (cont.)

• This is proof of concept project and the concept is very vague. SRS put bounds on it such that our clients now have to go through formal process before new requirement is added.

• It will help us scope the project

▫ We are currently investigating unknowns and we plan to formally scope it by the end of the spring

17

Agenda


• Process

• Requirements

• Risk Management


• Going Forward

• Accomplishments

• Questions?

18

Risk Management

• The system needs to transfer a lot of data between the handheld and the server; the system may become bottlenecked and prevent us from meeting our performance quality attribute.

• Based on the first prototype, Ptolemy runs below acceptable performance on the handheld and we intend to port parts of Ptolemy; the Ptolemy actors might perform below the defined performance quality attribute.

19

Agenda


• Process

• Requirements

• Risk Management


• Going Forward

• Accomplishments

• Questions?

20

Quality Attributes

• Performance ▫ Real time data is processed at correct rate

• Extensibility

▫ New actors could be added within 2 person weeks

• Reliability ▫ Demonstration does not crash for 15 minutes

• Wow-ability ▫ Client demonstrates the system in front of executives and

inspire them

• Usability ▫ Handheld user can operate it without training

21

Architectural Styles

• Ptolemy – Pipe & Filter on steroids

▫ Multi threaded filters (actors)

▫ Filters running based on a schedule

▫ Filters communicate by passing tokens

• Client/Server

▫ Run sinks and sources on handheld and offload hard processing to the server using push communication protocol

22

Context Diagram

23

Handheld

Server

Desktop Ptolemy

Disk

Ptolemy Model

UI Designer

UI Design File

PushPush

Ptolemy ModelUI Design File

Legend

Component/Module

data flow

New

Existing

Modified

Model & UI Design

Persistence

Visualization Library

Uses

Builds on

*mixed perspective

Dynamic Perspective - Initialization

24

Dynamic Perspective – Simulation

25

Static Perspective - Communication

26

Physical Perspective

27

Design Decisions

• MQTT is an appropriate messaging protocol due to low overhead and since it’s designed for sensors

• Publish-subscribe should be used to satisfy requirements for real-time, reliable data delivery

• Broker will provide extensibility for sensors not connected to or currently supported by Android

• The design provides extension to run complete Ptolemy on Android (since actors are ported) by removing network communication if hardware permits

28

Agenda


• Process

• Requirements

• Risk Management


• Going Forward

• Accomplishments

• Questions?

29

Going Forward: Plan for the semester

• Learn and implement ACDM

• Investigate layout designer prototype options

• Define project scope more precisely

• Develop QA plan and coding standards

30

Going Forward: Plan for the semester

• Design proposal

▫ We have diagrams, but no formal documentation

• Training on Ptolemy and Android

▫ Ptolemy we already started

270 page architecture document

▫ Still plan to use Lattix to discover dependencies in Ptolemy

▫ Android training

31

Agenda


• Process

• Requirements

• Risk Management


• Going Forward

• Accomplishments

• Questions?

32

Accomplishments

Learned using and tailoring TSP

Software Requirements Specification

Learn Ptolemy design

Communication prototype

Initial system architecture

Learn & use ACDM

Architecture documentation

33

Agenda


• Process

• Requirements

• Risk Management


• Going Forward

• Accomplishments

• Questions?

34

Questions and Comments

• What’s a best way to analyze TSP data?

• How can we improve estimation if we have unknowns and tasks that are not repeatable?

• How do we measure whether communication between handheld and server is fast enough (with regards to latency, throughput)?

▫ Is the architectural style appropriate for real time data?

• How to ensure that dependencies of Ptolemy actors don’t bog-down the handheld?

• How do we balance prototyping and design without assuming too much?

▫ How much prototyping is “enough” prototyping?

35

Backups

36

Mobile Sensors

Model1/source1

Ptolemy engine

Android

Model1/Sink1

37

Non-Android Sensors

Model1/source-actor1

Model1/source-actor2

Ptolemy

android

Sensor

Sensor

Model/sink1

38

Quality Attributes-1

# Scenario Quality Attribute Priority

1

RTC gives a demo with the SoundSpectrum model to the Schwieberding teams using the Android device and providing a sound (file and microphone). The tool shows an analysis and suggests correctly the plausible cause Wow-ability High

2

The handheld end user, untrained and unfamiliar with the Ptolemy tool but familiar with handheld devices, runs the demo with minimal interactions and gets the results without making any mistakes Usability High

3

The handheld user, untrained, unfamiliar with the Ptolemy tool but familiar with handheld devices, explores the demo with no further instruction for 15 minutes and the demo does not crash Reliability High

4

A Ptolemy developer adds an existing graphical actor to be used for the handheld application, its incorporated into the desktop interface design and its displayable on the handheld within two person weeks Extensibility High

5

A Ptolemy developer adds an existing input actor to be used for the handheld application and incorporated into desktop interface designer, and the handheld connects the datasource to the model within two person weeks Extensibility High

6

The handheld user is running a model that experience an error that stops the normal execution, the handheld provides the user a way to cancel execution and return a default state and logs the error for future debugging Reliability High

7 The handheld user runs the sound spectrum model, the sensor data is captured at the correct rate and fed into the simulation with the order preserved Performance High

8

The Ptolemy interface designer creates an interface using the desktop tool. The end user uses the handheld device, downloads the interface, and the interface looks exactly like the desktop preview Usability High

9 The handheld user runs the sound spectrum model, the visualization feedback is not more than 20% slower than the desktop application Performance Medium

39

Quality Attributes-2

# Scenario Quality Attribute Priority

10

An interface designer is building a layout for a new android device with different dimensions and capabilities once the initial android version exits; user can design a layout with no code changes Extensibility Medium

11 Version 3.0 of Android comes out and layout builder and handheld application supports it without any code changes Extensibility Medium

12 Version 3.0 of Android comes out with new features, RTC can implement these features with no change to the architecture Extensibility Medium

13

RTC ports the system from Android to iPhone once Android version exists. RTC implements iPhone specific parts with zero changes changes to the systems architecture. Portability Medium

14

A Ptolemy developer modifies either handheld application or layout interface designer code. Any new defects that affect current code are caught by the existing tests Maintainability Medium

15

The handheld user runs a model that requires a wifi input and there is trouble connecting and/or data loss, the handheld notifies the user about the error and the user understands the problem Reliability Medium

16

A Ptolemy developer needs to maintain this system by making a change to the code and effort to understand and identify where the change needs to be made is 0 person/days Maintainability Medium

17

After the system has been built and deployed, developer wants to replace the current simulation implementation with a different code generated from the Ptolemy code generation package within 3 person/weeks Modifiability Medium

40

Static Perspective – UI Designer

41

Risk Management

• The project has many technical unknowns concerning the architecture, the team might not be able to discover enough to have a “go” decision by the end of the semester

• The estimations for tasks are consistently inaccurate and imprecise, therefore the team might not be able to reach the set milestones on time

• There's a lot of course load and stress on the team members, which means estimated resources and team morale might diminish.

42

Previous Software Experiments

• Code Generation

▫ Proposed by client and collaborator

• Porting complete Ptolemy to Android

▫ Too slow on handheld

▫ Switched to Client / Server based on the results

43

TSP Tool Screenshot

44

Mosp spring 2011

Education

Transcript of Mosp spring 2011