PDAs in Space

1. PDAs in Space PDAs in Space Development of onboardPDA based applications Maurizio MartignanoSerco FM BV c/o ESTEC - ESA, Postbus 299 The Netherlands Tel. +31-71-565-6749 Maurizio.Martignano@esa.int

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 - “Hardware Replacement” e.g. IMSIncrement 15 (March 2007)

5. PDAs onboard the Space Station - “Application Porting” e.g. PocketPC iPVPrototype ESA Study2005

6. PDAs onboard the Space Station - New / Specific Applications e.g. PDA Depresurrization Program Flight 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. 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.

13. 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]

14. 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 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. 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]

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

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

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