PDAs in Space
PDAs in Space
Development of onboard
PDA based applications
Maurizio Martignano
Serco FM BV
c/o ESTEC - ESA, Postbus 299
The Netherlands
Tel. +31-71-565-6749
May 06
© 2006 ESA All rights reserved.
 PDAs onboard the Space Station
 Prototypes / Applications
 Few Considerations on the Development Approach(es)
 What Next?
May 06
© 2006 ESA All rights reserved.
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.
May 06
© 2006 ESA All rights reserved.
PDAs onboard the Space Station -
Increment 15
(March 2007)
May 06
© 2006 ESA All rights reserved.
PDAs onboard the Space Station -
“Application Porting”
PocketPC iPV
ESA Study
May 06
© 2006 ESA All rights reserved.
PDAs onboard the Space Station -
New / Specific Applications
PDA Depresurrization Program
Flight 1E – July 2006
May 06
© 2006 ESA All rights reserved.
Prototypes / Applications: PDA
iPV 1
 ESA funded R&D
 Prime Developer: EADS –
 Platform: IBM Java J9
 Very close to the current
(laptop based) iPV from a
functional point of view
May 06
© 2006 ESA All rights reserved.
Prototypes / Applications: PDA
 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.
May 06
© 2006 ESA All rights reserved.
Prototypes / Applications: PDP
 PDA Depressurisation Program
 ESA Crew Office Initiated
 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
– Speech & Communication –
May 06
© 2006 ESA All rights reserved.
Few Considerations
 Purpose of the ESA funded R&D Development
– Verify the “maturity” of the PDA HW/SW development
– Verify / experiment the adoption of “Agile Development
 Purpose of the ESA funded PDP Development
– Implement a real application to be used by the astronauts onboard
the station  Need for qualification.
May 06
© 2006 ESA All rights reserved.
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.
May 06
© 2006 ESA All rights reserved.
Few Considerations (cont)
– 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.
May 06
© 2006 ESA All rights reserved.
Few Considerations (cont)
 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]
May 06
© 2006 ESA All rights reserved.
Few Considerations (cont)
 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
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
[their statement 2]
May 06
© 2006 ESA All rights reserved.
Few Considerations (cont)
 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]
May 06
© 2006 ESA All rights reserved.
Few Considerations (cont)
 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....
May 06
© 2006 ESA All rights reserved.
Few Considerations (cont)
 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.
May 06
© 2006 ESA All rights reserved.
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
May 06
© 2006 ESA All rights reserved.
What next? (cont)
 Interesting areas:
– Communications
• Alarms / Cautions and Warning broadcasting
• Peer-to-Peer (VOIP) Communication
– eBook
• Procedures
• Documentation
• Leisure
May 06
© 2006 ESA All rights reserved.
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.:
May 06
© 2006 ESA All rights reserved.

Laptops and PDAs