PDAs in Space Mauriziov1

33 %
67 %
Information about PDAs in Space Mauriziov1

Published on January 3, 2008

Author: AscotEdu

Source: authorstream.com

PDAs in Space:  PDAs in Space Maurizio Martignano Serco FM BV c/o ESTEC - ESA, Postbus 299 The Netherlands Tel. +31-71-565-6749 Maurizio.Martignano@esa.int PDAs in Space Development of onboard PDA based applications Agenda:  Agenda PDAs onboard the Space Station Prototypes / Applications Few Considerations on the Development Approach(es) What Next? PDAs onboard the Space Station:  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. PDAs onboard the Space Station -:  PDAs onboard the Space Station - e.g. IMS Increment 15 (March 2007) “Hardware Replacement” PDAs onboard the Space Station -:  PDAs onboard the Space Station - e.g. PocketPC iPV Prototype ESA Study 2005 “Application Porting” PDAs onboard the Space Station -:  PDAs onboard the Space Station - New / Specific Applications e.g. PDA Depresurrization Program Flight 1E – July 2006 Prototypes / Applications: PDA iPV 1:  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 Prototypes / Applications: PDA iPV2:  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. Prototypes / Applications: PDP:  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 Few Considerations:  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. Few Considerations (cont):  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. Few Considerations (cont):  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. Few Considerations (cont):  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] Few Considerations (cont):  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] Few Considerations (cont):  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] Few Considerations (cont):  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.... Few Considerations (cont):  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. What Next?:  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. What next? (cont):  What next? (cont) Interesting areas: Communications Alarms / Cautions and Warning broadcasting Peer-to-Peer (VOIP) Communication eBook Procedures Documentation Leisure What next? (cont):  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

Add a comment

Related presentations