Digital equipment and systems always include some form of software. After all, digital hardware wouldn’t be of much value without the software. Software sometimes goes by other names or euphemisms such as firmware or micro code. Less often, other software such as interpreters and compilers and utilities may be included or supplied with equipment or part of systems. Application or configuration software may be required for the equipment or system to function properly or meet requirements. Applications software might be the product of a third party developer. The possibilities are many, but what is important is what the requirements are or what was included in the order or supply agreement that caused the equipment to be delivered.
The digital television transmitter contains detailed specifications and a general approach to test and acceptance. This gives the potential supplier an idea of expected performance and an outline of proving the equipment meets or exceeds the specifications. What is not included is a detailed test plan. A test plan can be written from scratch by the buyer or alternatively provided by the supplier as part of the deliverables, subject to approval by the buyer. Both require significant effort to prepare and validate. Chances are the supplier or the manufacturer already has a detailed test plan for each component or subsystem used in the manufacturing process as well as a system test plan for a complete unit.
Making a manufacturer’s system test plan valid for use in accepting the equipment is dependent on emulating the intended use and environment. Essentially, this involves assembling the system as close as possible to the final operational configuration. In most cases this is not a big issue. However if the equipment or system will carry significant volumes of traffic, this may not be possible, except through the use of traffic generators. Again, the main concern is to carry out any and all steps included in the supply agreement. Simply making measurements and validating functions and features outlined in the supplier’s published specifications is prudent and helps to uncover and resolve any issues or concerns.
Acceptance of Circuits, Facilities, and Services
On the service provider side, similar concerns and processes exist. The governing approach is either in a tariff or some form of supply agreement. If not explicitly mentioned or called out, then the alternate approach is to use applicable ANSI, IEEE, IETF, ITU, or other applicable recommendations. The process and focus of the effort should be structured around the end-to-end service model block diagram. Initial concern is to make sure connectivity exists by examining and testing the underlying circuit or facility. Validating or accepting a new circuit on an existing facility is less complicated but riskier than accepting a new facility. Regardless, the process is fairly simple and very similar.
If the circuit or facility is intra–LATA (local), only one provider is involved. If it is inter-LATA (long-distance), three service providers are involved: two local exchange carriers and one inter-exchange carrier. If the service is international, the international portion will involve two more physical pieces and a local exchange carrier at the far end.
Circuit acceptance in any case involves a fairly simple process and requires relatively simple test equipment. When the service provider informs you that it is ready for acceptance, simply connect the equipment, loop back the circuit at the far end, and initiate a bit error rate performance test for at least 48 hours—preferably 72 hours. The circuit should perform error free. If there are errors, turn it back over to the provider and ask them to fix it.
Once the circuit or facility is accepted, then remove the bit error rate test equipment and replace it with the operational equipment (multiplexer, server, or whatever) and begin operational tests with the complete system.
