The development of SkyPipes’ products and systems will be done in phases to minimize technology risks and maximize the value of limited technical resources. SkyPipes' systems have both hardware components and software components. Several important guiding principles will be applied to direct the specific design and implementation choices we make in developing hardware and software. These design principles will reduce development time and costs, improve the efficiency and reliability of field deployments and operations, and support ongoing reductions in the costs of system components. They are:

• Use commodity off-the-shelf hardware components wherever possible--balanced against the need for superior performance. For example, this means using standard unmodified commodity radio transceivers such as 802.11g. Should we determine that modification of a radio’s firmware produces drastically superior performance then we may elect to do so while recognizing that it is at the cost of reduced price leverage over multiple radio vendors.
• Use open source software components wherever possible—balanced against the need for performance and maintainability. For example, we will likely use embedded Linux in all processors as opposed to proprietary real time OS systems (RTOS). However we must be sure that we have acquired the needed development tools and code management systems to assure that code integration and development, debugging and testing happens efficiently across a distributed code development environment.
• Design for minimum number of hardware module types over the life cycle of the technology. For example if an antenna/radio module must meet different radiated power constraints in different countries, work to create a design that can be adapted to different power constrains through software configuration rather than modified hardware design.
• Design for maximum backward compatibility. Except for Alpha test hardware, improvements in both hardware and software components should wherever possible be able to be introduced into existing SkyPipes networks and be expected to work without reducing the performance of existing network elements in a given network. It is acceptable to require the replacement or upgrade of other network elements to experience the benefits of an improvement to a particular network element.
• Design for live redundancy, hot swapability, and graceful performance degradation. For example centralized, service-effecting components like Anchor Points and Central Servers should be interconnectable in such a way that they share loads in the event that one of them is lost. Things like Anchor Point sector antennas or Central Server disk drives should be able to be replaced while a network is in service. The costs of a basic SkyPipes system should not be increased by the addition of these capabilities. But these fail-safe abilities should be available to service providers at additional cost.
• Software and firmware in all hardware components should be downloadable across the network. This capability should allow service provider control of in-field updates for all modules with “hot” cutover and roll back of software/firmware for in-service modules.
• All management and configuration of all hardware and software components in a SkyPipes system should be web based. These capabilities should provide for both local (at the node) and remote web access. All web management interfaces should provide for both machine readability and control as well as suitable GUI’s for human interaction with all modules and systems.