Systems engineering
Systems engineering is the method of accomplishing a system
design within the constraints of many conflicting goals. There is
no perfect system design, but instead a compromise among many
needs under constraints of time and effort. The system must begin
with a reasonable set of goals that can be accomplished in an
initial release, and must have the capability to be improved and
extended as future requirements are obtained. Some areas for
system trade-offs:
Customer and market needs
Telecommunications standards
Systems requirements
Software development needs and
constraints
System test needs and
constraints
Product improvement and upgrades
The problem of balance
It is important for the system engineer to take the broad
view, and try to obtain a balance among these competing needs.
The greatest barrier to obtaining this balance is that each of
these needs is represented by people who have a very specific and
partisan view of their own goals. For example, market-oriented
people may not wish to consider the constraints of development
schedules, and developers may prefer to design a system
independently of external standards. The system engineer has a
specific goal also, namely, the attempt to preserve the overall
integrity of the system design concept in the face of all these
competing demands.
In general, all groups and individuals need to compromise
within their particular areas. If certain groups are not willing
to compromise, and demand complete adherence to their own needs,
the overall system usually suffers.
The problem of scale
Systems engineering would not really be needed if all
development projects were very small-scale. For a product that
can be developed by a group of 10 people or fewer, for example,
formal systems requirements and formal systems design documents
would not be needed, since everyone on the team would generally
know the overall purpose and structure of the system.
Systems engineering becomes more important as development
projects grow in size, and becomes essential for large projects,
in which most people do not grasp the overall scope of the
project, and only focus on their particular portion of the
system. Systems engineering provides the glue that holds these
different groups and viewpoints together.
The relationship of systems engineering to technical
management also requires some comment. For small projects,
technical management generally provides the systems engineering
function, in that they define the major product features and
capabilities. For larger projects, the scope of the system
extends beyond the capabilities of any one person or small group,
and requires a systems engineering team devoted full-time to
managing the system features and design. Furthermore, on large
projects the technical management team is generally overburdened
by many additional tasks such as scheduling, obtaining funding,
working with senior management, etc., and therefore simply does
not have the time to make all the detailed decisions necessary to
keep the system development on track.
Systems requirements
Systems requirements define the rules to be followed when
designing a system. Systems requirements tend to be based on 2
major sources of information:
For the ideal system, customer and market needs and externally
defined standards would fully determine the system behavior.
However, there are inevitably compromises that must be made to
account for system implementation constrained by budgets and
schedules. As the system architecture progresses, and design
decisions are made, the structure of the system itself limits the
system's ability to conform to external requirements and new
customer needs, so that over time the system becomes less
flexible and less capable of adjusting to new requirements.
Some of the major requirements topics that must be defined for
optical telecommunications equipment design and development:
Transmission interfaces
Transmission channel
interconnections
Synchronization and timing
internal clock timing source
generation and distribution
external timing connections
network-level synchronization
issues
Redundant protection switching
internal equipment protection
(redundant circuit packs)
interface protection (1+1 or
1xN interface protection)
network protection (for
example, ring protocols)
Operations support
local and remote user
interfaces
connections to existing
customer operation support systems
operations support language,
syntax and semantics of user commands
Physical constraints
size
power consumption
wiring interconnection
I have written systems requirements in many of these areas,
mostly for Sonet and SDH optical transmission systems. My most
recent project at Lucent Technologies was the Wavestar Bandwidth
Manager (BWM) broadband Sonet/SDH digital cross-connect system. I
was responsible for systems requirements in electrical
interfaces, synchronization, and protection switching, as well as
the user interfaces for these areas.
Previously I wrote and maintained requirements for the FT-2000
lightwave transmission system, and for the first-generation
Optical Line System (OLS) Lucent DWDM product.
Telecommunications standards
My work has been mostly oriented towards the Synchronous
Optical Network (Sonet) and Synchronous Digital Hierarchy (SDH)
standards for digital transmission over optical networks. Within
AT&T Bell Labs, I assembled and presented the earliest
general tutorial seminar for Sonet/SDH, and presented it many
times throughout the company. Later this tutorial work was
continued by other people, as the Sonet standard became more
mature.
Sonet/SDH standards have later expanded to cover more areas of
optical transmission, and to provide more details in areas of
special interest such as synchronization, ring network
protection, and network operations. Since it would be a full-time
job to keep up with these standards, rather than providing
technical information I am providing references to organizations
which manage and teach these standards:
|