PDAs in Space

May 06© 2006 ESA All rights reserved.

1

PDAs in Space

Maurizio MartignanoSerco FM BVc/o ESTEC - ESA, Postbus 299The NetherlandsTel. [email protected]

PDAs in Space

Development of onboardPDA based applications


2

Agenda

PDAs onboard the Space Station

Prototypes / Applications

Few Considerations on the Development Approach(es)

What Next?


3

PDAs onboard the Space Station

PDAs are currently used onboard the Space Station as personal computing platforms (i.e. currently PDAs are not part of any Station application – neither at system nor at payload level)

There is anyhow a strong need to reduce the number of laptops used onboard (limited availability of Shuttle flights, too much power consumptions, etc...). This is why PDAs are starting to be considered as a possible alternative platform for some of the current applications (iPV, OSTPV, etc...).

PDAs could also be used as replacement for other hardware (e.g. barcode reader) and could be able to support/host more than one application, optimizing the onboard usage of computing platforms.


4

PDAs onboard the Space Station -

e.g.IMS

Increment 15(March 2007)

“HardwareReplacement”


5


e.g.PocketPC iPV

PrototypeESA Study

2005

“Application Porting”


6


New / Specific Applications

e.g.

PDA Depresurrization ProgramFlight 1E – July 2006


7

Prototypes / Applications: PDA iPV 1

ESA funded R&D Development

Prime Developer: EADS – Germany

Platform: IBM Java J9

Very close to the current (laptop based) iPV from a functional point of view


8

Prototypes / Applications: PDA iPV2

ESA funded R&D Development

Prime Developer: TERMA – The Netherlands

Platform: IBM Java J9 – Pocket Internet Explorer

Alternative implementation to the current iPV. Very interesting from the usability point of view.


9

Prototypes / Applications: PDP

PDA Depressurisation Program

ESA Crew Office Initiated Effort

Under qualification by NASA To be used first by

astronaut T. Reiter during his LDM and then by all crew member.

Platform:– GUI - C# on .NET Compact

Framework– Speech & Communication –

ANSI C


10

Few Considerations

Purpose of the ESA funded R&D Development– Verify the “maturity” of the PDA HW/SW development

platforms– Verify / experiment the adoption of “Agile Development

Methodologies”

Purpose of the ESA funded PDP Development– Implement a real application to be used by the astronauts

onboard the station Need for qualification.


11

Few Considerations (cont)

Maturity of the HW/SW Platform– HW: iPAQ 5550 (req. from the Station), it is going to change

– Software:• Both R&D studies eventually selected the IBM J9 JAVA Virtual

Machine, with Personal Profile for the PocketPC.• GUI handling by Java still problematic:

– Inefficient – AWT? / SWT? / Swing?

• Too many Java Virtual Machines (J9, Jeode, Creme, Mysaifu, etc...) and the WORA acronym is just a myth.

• The .NET Compact Framework (and in general Microsoft products, libraires and languages) are still more mature on the PocketPC.

• “Unmanaged” ANSI C is still the fastest and most efficient language.


12


– Software• IDEs like IntellyJ Idea or Eclipse/Websphere on the Java side and

Visual Studio on the .NET side are mature, capable (perhaps too capable) and provided more features of what required.

Usability– The PDA is not a (micro) PC Special attention must be

payed at the design/development of the GUI, driven by the limited real estate and by the available input and output devices (stylus, programmable buttons, virtual keyboard, voice, etc...)

– Both R&D applications were subject to crew evaluation in front of real hardware, at EAC.


13


Usability– ESA work, especially on the PDP application, has led to

drafting of a PDA Annex in the ISS Display Standards.

Agile Methologies and Space Applications– Both R&D development teams tried to find some sort of

compromise between the Agile Methodologies and the somehow sequential software development process implyed by ECSS E-40.

[their statement 2]


14


EADS Team Defined Process– Flexible handling of requirements baseline via use cases– Controlled development via short iteration cycles and continuous build– Usability as well as overall quality through early prototyping and acceptance

testing in step with development as well as the integration of users and customers in the iteration planning

– Maintainability through enforced coding standards monitored by product metrics– Process stability through continuous monitoring of process metrics related to cost,

effort, open issues– Compliance with ECSS E-40 is achieved by maintaining the usual review points, but

with a relaxation of the status of the review data package– Customer/user oriented development by early prototyping, CRC cards and paper-

prototypes as basis for discussion;– Integration of user/customer representatives at iteration closeout meetings in

addition to the usual review participation. – Recommended a bi-weekly basis, but for our purposes 3-4 weeks due to the little

availability of end-users[their statement 2]


15


The TERMA led consortium proposed a lifecycle based on dX, which is based on the Rational Unified Process (RUP).– The dX process defines the four phases of the RUP; Inception,

Elaboration, Construction and Transition.– The approach proposed by TERMA implies that at any one time

in an agile process, there must be:• A clear set of high level use cases driving the requirements• A clear set of regression and unit tests for each case• Code that is claimed to be working must pass its unit tests

– To tackle with the restrictions imposed by formal reviews TERMA proposed that the current phase of the project should be determined by the fact that the stakeholders of the project have reached a particular state of understanding. This is perhaps analogous to the various "states" of an ECSS-compliant project, but not fully.[their statement 2]


16


PDP Process– The PDP process was very “Agile”: direct/immediate

iterations between the (single – the presenter) developer and the (single – T. Reiter) user...

– But...– Once the product was accepted by the (single) user it had

to be qualified by NASA...– ... this required if not a standard software life cycle, the

actual production of the standard set of documents....


17


The suitability of the “Agile Methodologies” may depend on the criticality of the application at hands.

It could make sense to divide the application under development into different layers, different subsystems having different levels of criticality.

When this partitioning is done “Agile Methodologies” could be applied to less critical components, providing a strong interaction with the end user.


18

What Next?

PDAs have proved to be platforms powerful enough to run quite complex and significant applications.

The migration of applications from the laptops to the PDAs could be done but only as the result of a full, system level, end-to-end architecture and usability analysis.


19

What next? (cont)

Interesting areas:

– Communications• Alarms / Cautions and Warning broadcasting• Peer-to-Peer (VOIP) Communication

– eBook• Procedures• Documentation• Leisure


20

What next? (cont)

– Client / Server• Simple remote terminals to server applications

– Electronic assistance for long duration missions• ePartner – MECA study

– Synoptic Displays / (SCADA?)• Remote control and commanding, e.g.:

http://www.instanthmi.com/

http://www.iconics.com/products/pocketgenesis.asp

PDAs in Space

Documents

Transcript of PDAs in Space