The incorrect component can prove quite costly...
In any industry — especially in the military/agency/ government (MAG) market segments — an incorrect component can, and does, prove costly. In space, this cost can be several orders of magnitude higher. Chip development for satellites and their specifications will assist developers in being correct at the first time around.
The consequences of being late to market can be devastating to a an organization or company, especially when the costs for many products are measured in millions of dollars, whether tax payer or commercial entity supported.
A delayed launch due to late breaking changes could significantly delay services revenue and also prove disastrous to warfighters. Once a satellite is on-orbit, it’s extremely difficult and, sometimes, impossible to service.
Getting it wrong can be even more catastrophic.
The maiden flight of Ariane 5 lasted one minute before the rocket — along with its $500 million payload — was destroyed. The cause of this was the specification of the software used, which suffered from a poor definition of detailed requirements and functionality. That ultimately led to software performing 64-bit operations with 16-bit precision and failing to correctly detect overflow conditions.
It’s not just the software — much of the electronics used in satellites are ASICs (custom-designed chips), which deliver the bespoke functionality needed while meeting, for example, the power limitations required when operating only on solar and battery power.
As an example, the company recently worked with ESA as a partner to develop a satellite communications system for a spacecraft and this required a Ka-band (26.5 – 40 GHz) transceiver in order to communicate with vehicles anywhere on the planet.
Again, the design for this began with the specification.
To quote five IC design experts* … “Tell me what you want. What you really, really want.”
Purpose oF the Specification
The specification defines the behaviour and operation of the product. Functionality and behaviour which is required to be present in the product must be clearly defined. Similarly, functionality that is explicitly not required should also be clearly stated.
Typically, the specification is generated by the engineering team in consultation with the end customer and based on a requirements document provided by the customer.
One key mistake that is frequently seen is the assumption that the specification can function as a datasheet and/or user manual — let’s stress that the specification is not this document.
Instead, the specification is there to confirm customer requirements. Every requirement must be addressed directly or indirectly by the functionality defined within the specification.
There is a one to one (or one to many) mapping between each customer requirement and functionality defined by the specification.
Therefore, it is essential to review and approve the specification only when it adequately responds to each requirement. The compliance report that is prepared by the development team should be closely reviewed and then approved by the customer.
Who Is the Specification For?
There are two audiences.
1) The system developer (the ASIC vendor’s customer). If the customer does not understand or agree with the definition of the product, the chances that a development team is able to deliver what’s needed tends to zero.
2) The development team. While this sounds obvious, it is all too common for individual members of a development team to only read the sections of the specification focused on their tasks. For the development team, the specification document allows the team to be structured correctly to bring together the right skillsets.
While the specification cannot magically resolve poor communication between the customer and the supplier, or between people within the suppliers product development team, it will act as the communication channel that will help the information to flow to the correct parties.
The Seven Rules to writing Requirements?
1) Use precise language
The choice of words used to express each requirement is crucial. As an example: shall expresses a requirement; will makes a statement of fact; should expresses an aspiration.
2) Be concise
Each requirement should be as concise as possible, with requirements reduced into individual items, giving maximum clarity when reporting compliance during the development. For example, it is preferable to say, “The product must do X” and “The product should do Y” rather than “The product must do X and should do Y.”
3) Be complete
The requirements must be complete. If an aspect of the necessary product functionality is not described in the requirements, it will not be described in the specification and, as a result ,will not be in the product.
4) Include rationales
but only where essential Where appropriate, each requirement may be accompanied by a rationale. The rationale is not an extension of the requirement. Compliance is determined against the requirement, not the rationale. Do not fall into the trap of using the rationale in an attempt to broaden the scope.
5) Focus on the what, not the how
The requirements must describe the intended functionality but equally must not describe the preferred implementation. The requirements describe what the product must do rather than how it must provide that functionality.
6) Ignore non-essential functionality
Is each requirement necessary for the product? If something is not essential for the intended product functionality then it is not a requirement.
7) Make requirements specific and measurable
For reporting compliance there must be a way to uniquely identify each requirement. This enables compliance reports to make clear statements such as “Specification S.17 addresses requirement R.49”. Writing clear, unambiguous requirements means the avoidance of any terminology or expression that is not verifiable. As a basic example, saying “The product must be low power” is subjective — instead, it should be defined as “The product must consume less than X.”
Getting a specification wrong can be catastrophic for MAG and/or commercial projects. By following these seven tips, developers should be well placed to ‘get it right first time.’
Paul Morris is VP of the RF and Comms Business Unit at ASIC development company EnSilica. The company works with a number of SATCOM and automotive system developers, including the European Space Agency.
www.ensilica.com