There are several tools that are frequently used by systems engineers:
The first significant systems engineering was performed for telephone systems. All the different parts of the phone system have to interoperate reliably. An excellent overview of the interfaces? and logic, with some history, is "Digital Telephony" by [John C. Bellamy]?.
When a system manipulates some physical? process?, simulation and modeling are important. Aircraft are usually modeled and simulated before flight?. In this way the aeroelastic engineering and control equations can be corrected before the physical system is constructed. Since aircraft are often very expensive, this saves the expense and difficulty of debugging the controls by crashing real aircraft.
System engineers perform testing and validation when a system has to have predictable behavior. For example medical machinery? such as heart? and lung? machines usually consist of several parts, engineered by different companies. Testing and validation assures that normal operation and possible failures of each part will not harm the patient?. Other applications are communications systems, or banking? software, where failures can cause loss of property or liability. Test plans can often be adjusted to save significant amounts of money, by testing partial systems, or including special features in a system to aid testing.
Safety engineering is applied to systems to assure that the systems cannot cause harm.
The techniques of safety engineering can be applied by everyday people to planning complex events. Most of safety engineering is just a way of making plans that cope with failures.
Usually a failure in safety-certified systems is acceptable if less than one life per 30 years of operation (10^9 hours) is lost to mechanical failure. Most Western nuclear reactors, medical equipment and commercial aircraft are certified to this level.
Interface design and specification are concerned with making the pieces of a system interoperate. For example, the plugs between two computer systems can be a fertile source of failures. Sometimes something as simple as gold-plating the plugs can lower the probability of a failure enough to save millions of dollars. Another issue is assuring that the signals that pass from system to the next are in tolerance, and that the receivers have a wider tolerance.
One of the tricks used by experienced system engineers is to place reserved wires, plug-space, command codes and bits in communication protocols. The rule of thumb is that roughly 20% of the space in an interface should be reserved for future additions.
This leads naturally to the design of communication protocols.
Usually, protocols are layered. For example, one layer might describe how to encode text (with ASCII, say), while another describes how to inquire for messages (with the internet's simple mail transport protocol, for example), while another may correct errors (with the internet's transmission control protocol), another handles addressing (say with IP, the internet protocol), another handles the error detection (with the internet's point-to-point protocol), and another handles the physical form of the bits, (with a V.42 modem, for example).
Layering allows the parts of a protocol to be designed and tested without a combinatorial explosion of cases, keeping each design relatively simple. Layering also permits familiar protocols to be adapted to unusual circumstances. For example, the mail protocol above can be adapted to send messages to aircraft. Just change the V.42 modem protocol to the INMARS LAPD data protocol used by the international marine radio satellites.
It's a truism? that communication media are alway faulty. The conventional measure of quality is failing bits per bit transmitted. This has the wonderful feature of being a dimensionless figure of merit that can be compared across any speed or type of communication media.
Conventionally, failure rates of 1x10-4 bit per bit are faulty (they interfere with telephone conversations), while 1x10-5 bit per bit or more should bring slow maintenance (they can be heard).
Communication systems correct errors by selectively resending bad parts of a message. For example, in TCP (the internet's transmission control protocol), messages are divided into packets, each of which has a checksum. When a checksum? is bad, the packet is discarded. When a packet is lost, the receiver acknowledges all of the packets up to, but not including the failed packet. Eventually, the sender sees that too much time has elapsed without an acknowledgement, so it resends all of the packets that have not been acknowledged. At the same time, the sender backs off its rate of sending, in case the packet loss was caused by saturation of the path between sender and receiver. (Note: this is an over-simplification: see TCP for more detail)
In general, the performance of TCP is severely degraded in conditions of high packet loss (more than 0.1%), due to the need to resend packets repeatedly. For this reason, TCP/IP connections are typically either run on highly reliable fibre networks, or over a lower-level protocol with added error-detection and correction features (such as modem links with ARQ). These connections typically have uncorrected bit error rates of 1x10-9 to 1x10-12, ensuring high TCP/IP performance.
Another form of network failure is topological failure, which a communcations link is cut. Most modern communication protocols periodically send messages to test a link. In phones, a framing bit is sent every 24 bits on T1 lines. In phone systems, when "sync is lost,", fail-safe mechanisms reroute the signals around the failing equipment.
In packet-switched networks, the equivalent functions are performed using router update messages to detect loss of connectivity.
![[Home]](wikipedia.png)