Unit 6
SYSTEM ENGINEERING
COMPUTER-BASED
SYSTEMS:
Definition: a
computer-based system as A set or arrangement of elements that are organized to
accomplish some predefined goal by processing information.
The
goal may be to support some business function or to develop a product that can
be sold to generate business revenue. To accomplish the goal, a computer-based
system makes use of a variety of system elements
Software.
Computer programs, data structures, and related documentation that serve to affect
the logical method, procedure, or control that is required.
Hardware.
Electronic devices that provide computing capability, the inter[1]connectivity devices (e.g.,
network switches, telecommunications devices) that enable the flow of data, and
electromechanical devices (e.g., sensors, motors, pumps) that provide external
world function.
People.
Users and operators of hardware and software.
Database.
A large, organized collection of information that is accessed via software.
Documentation.
Descriptive information (e.g., hardcopy manuals, on-line help files, Web sites)
that portrays the use and/or operation of the system.
Procedures.
The steps that define the specific use of each system element or the procedural
context in which the system resides.
To
summarize, the manufacturing cell and its macro elements each are composed of
system elements with the generic labels: software, hardware, people, database,
procedures, and documentation.
THE
SYSTEM ENGINEERING HIERARCHY
The
role of the system engineer is to define the elements for a specific computer[1]based system in the context
of the overall hierarchy of systems (macro elements).
The
system engineering process usually begins with a “world view.” That is, the
entire business or product domain is examined to ensure that the proper
business or technology context can be established. The world view is refined to
focus more fully on specific domain of interest. Within a specific domain, the
need for targeted system elements (e.g., data, software, hardware, people) is
analyzed. Finally, the analysis, design, and construction of a targeted system
element is initiated. At the top of the hierarchy, a very broad context is
established and, at the bottom, detailed technical activities, performed by the
relevant engineering discipline (e.g., hardware or software engineering), are
conducted.
System
Modeling:
System
engineering is a modeling process. Whether the focus is on the world view or
the detailed view, the engineer creates models that --
•
Define the processes that serve the needs of the view under consideration.
•
Represent the behavior of the processes and the assumptions on which the
behavior is based.
•
Explicitly define both exogenous and endogenous input3 to the model.
•
Represent all linkages (including output) that will enable the engineer to better
understand the view
To
construct a system model, the engineer should consider a number of restraining
factors:
1. Assumptions
that reduce the number of possible permutations and variations, thus enabling a
model to reflect the problem in a reasonable manner.
2. Simplifications
that enable the model to be created in a timely manner. To illustrate, consider
an office products company that sells and services a broad range of copiers,
faxes, and related equipment.
3. Limitations
that help to bound the system.
4. Constraints
that will guide the manner in which the model is created and the approach taken
when the model is implemented.
5. Preferences
that indicate the preferred architecture for all data, functions, and
technology.
System Simulation:
Many computer-based systems interact with the real world in a reactive fashion. That is, real-world events are monitored by the hardware and software that form the computer-based system, and based on these events, the system imposes control on the machines, processes, and even people who cause the events to occur. Real-time and embedded systems often fall into the reactive systems category.
Unfortunately,
the developers of reactive systems sometimes struggle to make them perform
properly. Until recently, it has been difficult to predict the performance,
efficiency, and behavior of such systems prior to building them.
In
a very real sense, the construction of many real-time systems was an adventure
in "flying." Surprises (most of them unpleasant) were not discovered
until the system was built and "pushed off a cliff." If the system
crashed due to incorrect function, inappropriate behavior, or poor performance,
we picked up the pieces and started over again.
Many systems in the reactive category control machines and/or processes (e.g., commercial aircraft or petroleum refineries) that must operate with an extremely high degree of reliability. If the system fails, significant economic or human loss could occur. For this reason, the approach described by Graham is both painful and dangerous
Today, software tools for system modeling and simulation are being used to help to eliminate surprises when reactive, computer-based systems are built. These tools are applied during the system engineering process, while the role of hardware and software, databases and people is being specified. Modeling and simulation tools enable a system engineer to "test drive" a specification of the system.