Personal digital assistants in space
| | ESA astronaut Thomas Reiter exercizing the PDA
| | Personal Digital Assistants (PDAs) are currently being considered as a promising hardware platform for a number of operations aboard the International Space Station (ISS). Their small size, weight, and power consumption, together with their increasing computing and storage capabilities make them very attractive for applications where use of a laptop is not possible or practical. They are also being considered as a complementary tool for astronaut operations, for instance to execute applications such as Operations Data File (ODF) procedure viewers or emergency procedures. However, these commercial devices are not generally suitable for space. Their technology evolves too quickly; they have a short life-cycle in the market and consequently a limited maintenance life. Space applications are not their primary target, they require heavy user interaction while offering reduced size screens and touch screens to astronauts in a microgravity environment or equipped with gloves, and they make extensive use of COTS software whose quality is not at the level required by space software standards. In order to use them as a space software platform, it was necessary to use them in an innovative way. Two parallel studies The ‘PDAs in Space’ study was started with the intention of covering several goals at different levels.
Luckily, two highly interesting proposals with complementary but equally valuable approaches allowed ESA to grant two parallel contracts. The final presentations and final reports of these studies are accessible using the right-hand menu.
Lessons learnt Many valuable lessons have been learned, the most important of which are:
- the only goal that clearly requires a different approach is the ‘application domain clarification or construction’. The term ‘construction’ is, indeed, absolutely relevant:
- the biggest return on investment for this study at application domain level will not be the experience gained but the increased awareness. That is already an oblique form of domain construction, which can possibly be improved with a more proactive approach
- it is foreseeable that the clarification of the possible uses of PDAs on board will be the result of the agreement among the ISS partners at the highest level
- the suggestion that they are too disruptive or valid only for niche applications seems too pessimistic
- the role of PDAs on board seems to be moving in the direction of their acting as user terminal for wireless connected applications where the difficult computational tasks and data-mining is performed by the servers
- the companies involved perceive some of the ‘agile’ principles as a must for user-centred software development that could really help in the development of on-board man-machine interfaces. This approach requires some clarifications:
- contractual and practical aspects prevent projects with ‘open-ended’ requirements. Some preliminary solutions have been proposed
- some adaptation of the ‘agile’ principles is required for purely technical reasons. It is agreed that software architectures are less flexible than claimed by ‘agile’ proponents
- user (that is, ISS crew member )availability is expected to be less than desirable and some adaptation of ‘agile’ principles is required to cope with this situation
- PDA specifics have a very strong impact on the definition of appropriate methodologies and lifecycles at least for the following aspects
- user interface design and implementation
- resource management
- architecture selection
- some valuable results have been obtained regarding development environments:
- Eclipse has been preferred as a software development environment over other possible choices, such as IntelliJ IDEA or the IBM WebSphere suite. The latter, although quite complete in general, was lacking some support specifically for the PDA development.
- none of the evaluated SDEs cover relevant aspects of the ECSS-E40 standard like, for example, support for traceability, documentation
- one of the teams filled this gap quite satisfactorily with an in-house XML based ‘tool’
- there is no simple, easy solution to build a complete software engineering environment covering the requirements of the standards and the needs of the developers. The best possible option is currently a pragmatic, loose combination of an SDE and other tools
- semantic support for refactoring, in particular when smoothly integrated with configuration management tools, makes a real difference
- for the Java platform and compatible COTS technologies:
- Java technologies provide a mixed picture. There is no particular reason to reject its use in favour of other technologies, or to advocate it. Programmatic aspects and specific support for intended features are relevant to making a decision
- one of the teams built a COTS-based application using a web browser as the GUI. It was well received by the users. The other alternative exercised in this study is the non-trivial construction of a rendering engine for the specific data to be displayed
- both Java and other COTS technologies show problems and limitations that do not appear in their desktop counterparts
Two prototypes were developed. The first delivers a more operationally aware functionality, while the second offers a very promising GUI. The prototypes have already been demonstrated to ESA and NASA crew with very positive reactions, particularly regarding the one using the web browser as rendering engine.
Last update: 21 March 2007
| | More information
| | PDA in space (ppt) (ftp://ftp.estec.esa.nl/pub/wm/anonymous/wme/Web/PDAs_in_SpaceMauriziov1.ppt) | |
|