Designers of electronics products are under ever increasing pressure to reduce development expense, reduce design cycle time, and reduce manufacturing cost at the same time that product complexity and reliability demands are increasing. A practical solution available to both government and industry is the use of open system architectures in product development. Engineers at the EMPF have effectively utilized open architecture solutions for re-designing communications systems for DOD in its various legacy system sustainment efforts.

Open architecture is defined as a hardware or software architecture whose specifications are available in whole or in part to the public. They include both architectures approved by various standards or trade organizations (e.g. Unix) and independently designed architectures whose specifications are made public by its owners (e.g. Peripheral Component Interconnect (PCI)). Proprietary systems, such as Microsoft Windows operating system, does not have its core technology available to the public but is included in the open architecture solution category because of the numerous open interfaces available to the public from a variety of sources. In contrast, closed system architecture specifications and interfaces are not available in the public domain. Incorporating other hardware or software products is difficult because of the unique interfaces in the architecture. The end result of a closed architecture is that practically only hardware and software from the same company can be used together. A closed architecture solution may provide a near term edge in features and/or performance over an open architecture system but market pressures from competition will most likely erase the edge and give the open architecture system the price/performance lead.

Open architecture system specifications are often controlled by an objective third party industry organization but no single developer or vendor has control over its use in various applications. Anyone can develop products for or improve the architecture or technology at any time, without obtaining permission from a vendor. The architecture evolves through the input of multiple developers and vendors. As the architecture matures, compliance tests certify that the specification is met. An open architecture standard should define for developers what the baseline, commodity architecture, or system should look like. An open architecture should ensure that systems are interoperable and that applications are readily portable, giving users, vendors and developers consistent and reliable access to the technology for their specific needs; it should not define what their specific needs are. Open architecture generates competitive market forces promoting technical innovation and lower costs for the designer.

Designers can easily develop hardware and/or software products that manufacturers can integrate into an open architecture system. Some of the advantages of using open system architectures in the design process include:

• Standard interfaces allow market forces to generate a variety of innovative, competitively priced, high performance product solutions for the designer to choose from.
• The designer can focus on generating product content instead of generating a framework. For example, when designing a software radio, a designer can purchase cPCI or VME cards, backplanes, and an operating system that work as a system permitting an immediate design focus on issues regarding the radio function.
• Open architecture is familiar to a larger technical population making it easier to find experienced personnel to support the project.
• Standard architecture already comes with a significant investment in application testing, far more than what most development programs can afford.
• The design cycle time is significantly reduced.

The following three scenarios illustrate the flexibility in using open system architecture to meet design requirements.

Design Scenario One
There is a requirement to design an application specific integrated circuit (ASIC) with a PCI bus interface. There are two options available to meet this requirement. The designer can either purchase a core from a vendor or design their own based on the PCI architecture specification. Since the basic functionality is defined in the specification, the vendor cores and their own design will compete on cost, performance and features. When the ASIC is released, the PCI interface has to pass special interest group (SIG) certification. Again, the designer has two options to meet the certification. During simulation the designer can either write test cases against a well defined architecture or purchase a test suite that guarantees compliance.

Design Scenario Two
In a proposed system, there is a need to transfer serial data at a specified rate over a given distance in a specific environment. Specifications of various buses can be gathered (e.g. RS-232, CAN, Ethernet), analyzed, and the trade-offs can be made to choose the architecture that best meets the performance and cost targets.

Design Scenario Three
An existing system has to be upgraded from an obsolete proprietary system to an open architecture system. Processing, communications and control functionality has to be provided. It has to meet a specific performance and power requirements and fit in a specified enclosure. PCI, cPCI, VME, and PC104/104plus are some of the open architecture systems that will be investigated. Several architectures may provide the required functionality, which allows the designer to select the best solution based on other factors such as available support, cost, and experience with a given system. Open architectures are extremely important because they enable the combination of products from different manufacturers to create a customized system.
Unfortunately, all design solutions cannot be met solely using an open architecture system. There are some applications that are so unique that the market cannot support multiple developers or vendors. However, even a unique system solution should specify requirements and interfaces in order to use open architectures when applicable (i.e. a hybrid solution). For example, many military system requirements have to be developed to meet harsh environmental and functional demands. Some elements of the system may be specified as an open architecture system enabling the developers to rapidly assemble the core of their system and spend more time on the unique requirements of the design. The software requirements of a military application may dictate a COTS solution where the data transfer rate can be determined and an open architecture bus can be selected to meet the throughput requirements. A processor or processor array in a COTS card can be selected to meet the processing requirements. Standard video, communications and control interfaces can be selected as well as the operating system, yielding a system that is sustainable from a number of vendors.

In conclusion, open system architectures can provide the developer of both commercial and military applications with proven system solutions that provide required functions in a framework that reduces development expense, increases product reliability, and improves the chances of a first pass design success. In a market where the Department of Defense is becoming a smaller influence as a driver of electronics technology development despite its increasing dependence on electronics in its systems, the use of open architecture systems in re-design and sustainment efforts for legacy systems is increasing.

Terminology/Definitions

• PCISIG- Peripheral Component Interconnect Special Interest Group
• PCI- Peripheral Component Interconnect
• COTS- Commercial Off The Shelf
• OS- Operating System
• ASIC- Application Specific Integrated Circuit
• CPCI- Compact Peripheral Component Interconnect
• CAN- Controller Area Network
• VME- Versa Module Europa
• VITA- VME International Trade Association