The document provides an overview of the HandSimDroid project. It includes an agenda for a meeting covering the project overview, process, requirements, risk management, system architecture, next steps, and accomplishments. The team used the Team Software Process and developed requirements, risk management plans, architectural diagrams, and plans to move forward with additional training, prototyping, and formalizing the project scope. They discussed accomplishments from the first part of the project and took questions.

1. Team HandSimDroid
Anar Huseynov
Ishwinder Singh
Justin Killian
Peter Foldes

2. 2
Agenda
• Project Overview
• Process
• Requirements
• Risk Management
• System Architecture
• Going Forward
• Accomplishments
• Questions?

3. 3
Agenda
• Project Overview
• Process
• Requirements
• Risk Management
• System Architecture
• Going Forward
• Accomplishments
• Questions?

4. 4
Team HandSimDriod
Team Lead
Process/Quality Planning Manager Development/
Manager Support Manager
Mentors Clients
TSP Coach

5. 5
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.

6. 6
Ptolemy Desktop Application
Model
Output

7. 7
Project Goals
• Show simulations running on
the handheld
• Enable UI customization by
model and per user
• Create demonstrations that
showcase usefulness of
functionality to engineers

8. 8
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

9. 9
Agenda
• Project Overview
• Process
• Requirements
• Risk Management
• System Architecture
• Going Forward
• Accomplishments
• Questions?

10. TSP Process

11. 11
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

12. 0 20 40 60 80 100
1/19/2011
1/26/2011
2/2/2011
2/9/2011
2/16/2011
Earned Value
2/23/2011
3/2/2011
Team Software Process Cont.
Ideal EV
Actual EV
12

13. 13
Long Term Plan
2010 Fall (732 hours) 2011 Spring (720 hours) 2011 Summer (2304 hours)
Sep. Oct. Nov. Dec. Jan. Feb. March April May June July Aug.
SOW
TSP Training
Planning SRS
DONE
Design Proposal
SRE
Tool Setup
Planning
TODO High level Design
Proposals
Experiments
Implementation
Requirements • Communication
• UI toolkits • Ptolemy on Android
• Contextual design
• Token overhead • UI Layout Tool
• Use cases
• Paper prototypes • Sensor throughput limits
Design Detailed Design Testing
• Notional
Architecture
• Experiment 1
• Experiment 2
User Guide
QAW
Milestone
EOSP MOSP EOSP EOSP

14. 14
Team Software Process Cont.
Effort by Assembly
2% 2% 1%
3%
3%
MEETING
6%
ARCHITECTURE
MOSP
7% 43% SRS
TRAINING
MISC
9% PLANNING
DATA
SYSTEM
PROPOSAL
24%

15. 15
Agenda
• Project Overview
• Process
• Requirements
• Risk Management
• System Architecture
• Going Forward
• Accomplishments
• Questions?

16. 16
Priority Requirement Document
Low Priority, 5
High Priority
High Priority, 30 Medium Priority
Medium Priority,
25 Low Priority

17. 17
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

18. 18
Agenda
• Project Overview
• Process
• Requirements
• Risk Management
• System Architecture
• Going Forward
• Accomplishments
• Questions?

19. 19
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.

20. 20
Agenda
• Project Overview
• Process
• Requirements
• Risk Management
• System Architecture
• Going Forward
• Accomplishments
• Questions?

21. 21
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

22. 22
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

23. 23
Context Diagram
*mixed perspective
Legend
Handheld Desktop
Ptolemy Component/Module
New
Push Push Ptolemy Model
Existing
Model &
UI Design
Ptolemy Model Persistence
Server Disk
UI Design File
Modified
UI Design File
Uses data flow
Visualization
UI Designer
Library Builds on

24. 24
Dynamic Perspective - Initialization

25. 25
Dynamic Perspective – Simulation

26. 26
Static Perspective - Communication

27. 27
Physical Perspective

28. 28
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

29. 29
Agenda
• Project Overview
• Process
• Requirements
• Risk Management
• System Architecture
• Going Forward
• Accomplishments
• Questions?

30. 30
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

31. 31
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

32. 32
Agenda
• Project Overview
• Process
• Requirements
• Risk Management
• System Architecture
• Going Forward
• Accomplishments
• Questions?

33. 33
Accomplishments
Learned using and tailoring TSP
Software Requirements Specification
Learn Ptolemy design
Communication prototype
Initial system architecture
Learn & use ACDM
Architecture documentation

34. 34
Agenda
• Project Overview
• Process
• Requirements
• Risk Management
• System Architecture
• Going Forward
• Accomplishments
• Questions?

35. 35
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?

36. 36
Backups

37. 37
Mobile Sensors
Model1/source1
Model1/Sink1
Android
Ptolemy
engine

38. 38
Non-Android Sensors
Model1/source-actor1
Sensor
Ptolemy
Model1/source-actor2 Model/sink1
Sensor
android

39. 39
Quality Attributes-1
Quality
# Scenario Attribute Priority
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
1 and suggests correctly the plausible cause Wow-ability High
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
2 making any mistakes Usability High
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
3 crash Reliability High
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
4 handheld within two person weeks Extensibility High
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
5 to the model within two person weeks Extensibility High
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
6 state and logs the error for future debugging Reliability High
The handheld user runs the sound spectrum model, the sensor data is captured at the
7 correct rate and fed into the simulation with the order preserved Performance High
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
8 desktop preview Usability High
The handheld user runs the sound spectrum model, the visualization feedback is not more
9 than 20% slower than the desktop application Performance Medium

40. 40
Quality Attributes-2
Quality
# Scenario Attribute Priority
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
10 layout with no code changes Extensibility Medium
Version 3.0 of Android comes out and layout builder and handheld application
11 supports it without any code changes Extensibility Medium
Version 3.0 of Android comes out with new features, RTC can implement these
12 features with no change to the architecture Extensibility Medium
RTC ports the system from Android to iPhone once Android version exists. RTC
implements iPhone specific parts with zero changes changes to the systems
13 architecture. Portability Medium
A Ptolemy developer modifies either handheld application or layout interface
designer code. Any new defects that affect current code are caught by the existing
14 tests Maintainability Medium
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
15 user understands the problem Reliability Medium
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
16 person/days Maintainability Medium
After the system has been built and deployed, developer wants to replace the
current simulation implementation with a different code generated from the
17 Ptolemy code generation package within 3 person/weeks Modifiability Medium

41. 41
Static Perspective – UI Designer

42. 42
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.

43. 43
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

44. 44
TSP Tool Screenshot