pdf viewer in c# code project : How to copy pdf image to word control software platform web page windows asp.net web browser software-architecture-practice118-part1347

[ Team LiB ]
8.1 Relationship to the Architecture Business Cycle
The segment of the Architecture Business Cycle (ABC) that connects desired qualities to architecture is
the focus of this case study. Figure 8.1
shows the ABC for Structural-Model-based flight simulators. The
simulators discussed in this chapter are acquired by the U.S. Air Force. Their end users are pilots and
crews for the particular aircraft being simulated. Flight simulators are used for pilot training in the
operation of the aircraft, for crew training in the operation of the various weapons systems on board, and
for mission training for particular missions for the aircraft. Some simulators are intended for standalone
use, but more and more are intended to train multiple crews simultaneously for cooperative missions.
Figure 8.1. Initial stages of the ABC for the flight simulator
The flight simulators are constructed by contractors selected as a result of a competitive bidding process.
The simulator systems are large (some as large as 1.5 million lines of code), have long lifetimes (the
aircraft being simulated often have lifetimes of 40 years or longer), and have stringent real-time and
fidelity requirements (the simulated aircraft must behave exactly like the real aircraft in situations such as
normal flight, emergency maneuvers, and equipment failures).
The beginning of the Structural Model pattern dates from 1987 when the Air Force began to investigate
the application of object-oriented design techniques. Electronic flight simulators had been in existence
since the 1960s, and so this investigation was motivated by problems associated with the existing
designs. These included construction problems (the integration phase of development was increasing
exponentially with the size and complexity of the systems) and life-cycle problems (the cost of some
modifications was exceeding the cost of the original system).
The Structural Model pattern was able to overcome these problems, as we will see. It has been used in
the development of the B-2 Weapons System Trainer, the C-17 Aircrew Training System, and the Special
Operations Forces family of trainers, among others.
[ Team LiB ]
This PDF file was converted by Atop CHM to PDF Converter free version!  http://www.chmconverter.com/chm-to-pdf/
Addison Wesley : Software Architecture in Practice, Second Edition
180 / 463
How to copy pdf image to word - copy, paste, cut PDF images in C#.net, ASP.NET, MVC, Ajax, WinForms, WPF
Detailed tutorial for copying, pasting, and cutting image in PDF page using C# class code
paste picture to pdf; paste image in pdf file
How to copy pdf image to word - VB.NET PDF copy, paste image library: copy, paste, cut PDF images in vb.net, ASP.NET, MVC, Ajax, WinForms, WPF
VB.NET Tutorial for How to Cut or Copy an Image from One Page and Paste to Another
how to copy picture from pdf and paste in word; paste picture pdf
[ Team LiB ]
8.2 Requirements and Qualities
There are three roles involved in a flight training simulator. The first is that of the crew being trained.
They sit inside a motion platform surrounded by instruments intended to replicate exactly the aircraft
being simulated, and look at visuals that represent what would be seen outside an actual aircraft. We are
not going to describe the specifics of either the motion platform or the visual display generator in this
chapter. They are driven by special-purpose processors and are outside the scope of the architecture we
describe here. The purpose of a flight simulator is to instruct the pilot and crew in how to operate a
particular aircraft, how to perform maneuvers such as mid-air refueling, and how to respond to situations
such as an attack on the aircraft. The fidelity of the simulation is an important element in the training. For
example, the feel of the controls when particular maneuvers are performed must be captured correctly.
Otherwise, the pilot and crew are being trained incorrectly and the training may be counter-productive.
The second role associated with a flight simulator is that of the environment. Typically, the environment is
a computer model, although with multi-aircraft training exercises it can include individuals other than the
pilot and crew. It comprises the atmosphere, threats, weapons, and other aircraft. For example, if the
purpose of the training is to practice refueling, the (simulated) refueling aircraft introduces turbulence into
the (modeled) atmosphere.
The third role associated with a flight training simulator is that of the simulation instructor. Usually, a
training exercise has a specific purpose and specific circumstances. During the exercise, the instructor is
responsible for monitoring the performance of the pilot and crew and for initiating training situations.
Sometimes these situations are scripted in advance, and other times the instructor introduces them.
Typical situations include malfunctions of equipment (e.g., landing gear that does not deploy correctly),
attacks on the aircraft from foes, and weather conditions such as turbulence caused by thunderstorms.
The instructor has a separate console to monitor the activities of the crew, to inject malfunctions into the
aircraft, and to control the environment. Figure 8.2
shows a typical collection of modern flight simulators.
Figure 8.2. Modern flight simulators.
Courtesy of the Boeing Company.
USE OF MODELS
The models used in the aircraft and the environment are capable of being simulated to almost arbitrary
fidelity. As an example of the range of fidelity, consider the modeling of the air pressure affecting the
aircraft. A simple model is that the air pressure is affected only by the aircraft altitude. Somewhat more
This PDF file was converted by Atop CHM to PDF Converter free version!  http://www.chmconverter.com/chm-to-pdf/
Addison Wesley : Software Architecture in Practice, Second Edition
181 / 463
C# PDF Image Extract Library: Select, copy, paste PDF images in C#
PDF ›› C# PDF: Extract PDF Image. How to C#: Extract Image from PDF Document. Support PDF Image Extraction from a Page, a Region on a Page, and PDF Document.
how to copy and paste a picture from a pdf document; paste image into pdf acrobat
VB.NET PDF Image Extract Library: Select, copy, paste PDF images
Home ›› XDoc.PDF ›› VB.NET PDF: Extract PDF Image. Support PDF Image Extraction from a Page, a Region on a Page, and PDF Document in VB.NET Project.
how to copy pdf image into word; how to copy a picture from a pdf
complicated is a model in which the air pressure is affected by altitude and local weather patterns.
Modeling local weather patterns takes more computational power but allows consideration of updrafts
and downdrafts. An even more complicated model with additional computational requirements is that the
air pressure is affected by altitude, local weather patterns, and the behavior of nearby aircraft. One
source of turbulence is an aircraft that has recently passed through the airspace of the aircraft being
simulated.
A consequence of the capability to simulate the aircraft or the environment to almost arbitrary fidelity is
that training simulators in the past always stressed the limits of computational power (and may always do
so in the future). Since crew simulator training is an important portion of overall flight training, there are
always strong arguments that slightly more fidelity will improve the training and hence the skill set of the
crews being trained. Performance, therefore, is one of the important quality requirements for a flight
simulator.
STATES OF EXECUTION
A flight simulator can execute in several states.
Operate
corresponds to the normal functioning of the simulator as a training tool.
Configure
is used when modifications must be made to a current training session. For example,
suppose the crew has been training in a single-aircraft exercise and the instructor wishes to switch
to mid-air refueling. The simulator is then placed into a configure state.
Halt
stops the current simulation.
Replay
uses a journal to move through the simulation without crew interaction. Among other
functions, it is used to demonstrate to the crew what they have just done, because the crew may get
caught up in operating the aircraft and not reflect on their actions. "Record/playback" was identified
in Chapter 5
(Achieving Qualities) as an architectural tactic for testing. Here we find it used as a
portion of the training process.
The simulators we discuss in this chapter are characterized by the following four properties:
1. 
Real-time performance constraints.
Flight simulators must execute at fixed frame rates that are high
enough to ensure fidelity. For those not familiar with frame rates, an analogy to motion pictures might
be helpful. Each frame is a snapshot in time. When a sufficient number of frames are taken
sequentially within a time interval, the user sees or senses continuous motion. Different senses
require different frame rates. Common simulator frame rates are 30 Hz or 60 Hz —one-thirtieth or
one-sixtieth of a second. Within each frame rate, all computations must run to completion.
All portions of a simulator run at an integral factor of the base rate. If the base rate is 60 Hz, slower
portions of the simulation may run at 30, 20, 15, or 12 Hz, and so on. They may not run at a
nonintegral factor of the base rate, such as 25 Hz. One reason for this restriction is that the sensory
inputs provided by a flight simulator for the crew being trained must be strictly coordinated. It would
not do to have the pilot execute a turn but not begin to see or feel the change for even a small period
of time (say, one-tenth of a second). Even for delays so small that they are not consciously
detectable, a lack of coordination may be a problem. Such delays may result in a phenomenon
known as 
simulator sickness
, a purely physiological reaction to imperfectly coordinated sensory
inputs.
2. 
Continuous development and modification.
Simulators exist to train users when the equivalent
training on the actual vehicle would be much more expensive or dangerous. To provide a realistic
training experience, a flight simulator must be faithful to the actual air vehicle. However, whether
civilian or military, air vehicles are continually being modified and updated. The simulator software is
therefore almost constantly modified and updated to maintain verisimilitude. Furthermore, the training
for which the simulators are used is continually extended to encompass new types of situations,
including problems (malfunctions) that might occur with the aircraft and new environmental
situations, such as a military helicopter being used in an urban setting.
This PDF file was converted by Atop CHM to PDF Converter free version!  http://www.chmconverter.com/chm-to-pdf/
Addison Wesley : Software Architecture in Practice, Second Edition
182 / 463
C# PDF Page Extract Library: copy, paste, cut PDF pages in C#.net
Ability to copy selected PDF pages and paste into The portable document format, known as PDF document, is a they are using different types of word processors.
how to cut and paste image from pdf; how to copy text from pdf image to word
VB.NET PDF Page Extract Library: copy, paste, cut PDF pages in vb.
Dim page As PDFPage = doc.GetPage(3) ' Select image by the point VB.NET: Clone a PDF Page. Dim doc As PDFDocument = New PDFDocument(filepath) ' Copy the first
paste image on pdf preview; how to cut an image out of a pdf
3. 
Large size and high complexity.
Flight simulators typically comprise tens of thousands of lines of
code for the simplest training simulation and millions of lines of code for complex, multi-person
trainers. Furthermore, the complexity of flight simulators, mapped over a 30-year period, has shown
exponential growth.
4. 
Developed in geographically distributed areas.
Military flight simulators are typically developed in a
distributed fashion for two reasons, one technical and one political. Technically, different portions of
the development require different expertise, and so it is common practice for the general contractor
to subcontract portions of the work to specialists. Politically, high-technology jobs, such as simulator
development, are political plums, so many politicians fight to have a piece of the work in their district.
In either case, the integrability of the simulator—already problematic because of the size and
complexity of the code—is made more difficult because the paths of communication are long.
In addition, two problems with flight simulators caused the U.S. Air Force to investigate new simulator
designs.
1. 
Very expensive debugging, testing, and modification.
The complexity of flight simulation software, its
real-time nature, and its tendency to be modified regularly all contribute to the costs of testing,
integrating, and modifying the software typically exceeding the cost of development. The growth in
complexity (and its associated growth in cost) thus caused an emphasis for the architecture on
integrability and modifiability.
One of the consequences of the growth in complexity was the increased cost of integration. For
example, a large completed Air Force system (1.7 million lines of code) had greatly exceeded its
budget for integration. Systems 50% larger were in concept, and they would have been prohibitively
expensive. Hence, integrability emerged as a driving architectural concern.
2. 
Unclear mapping between software structure and aircraft structure.
Flight simulators have
traditionally been built with runtime efficiency as their primary quality goal. This is not surprising
given their performance and fidelity requirements and given that simulators were initially built on
platforms with extremely limited memory and processing power. Traditional design of flight simulator
software was based on following control loops through a cycle. These, in turn, were motivated by the
tasks that caused the loop to be activated. For example, suppose the pilot turns the aircraft left. The
pilot moves the rudder and aileron controls, which in turn moves the control surfaces, which affects
the aerodynamics and causes the aircraft to turn. In the simulator, a model reflects the relationship
between the controls, the surfaces, the aerodynamics, and the orientation of the aircraft. In the
original flight simulator architecture, this model was contained in a module that might be called Turn.
There might be a similar module for level flight, another for takeoff and landing, and so forth. The
basic decomposition strategy was based on examining the tasks that the pilot and crew perform,
modeling the components that perform the task, and keeping all calculations as local as possible.
This strategy maximizes performance since any task is modeled in a single module (or a small
collection of modules) and thus the data movement necessary to perform the calculations is
minimized. The problem with this architecture is that the same physical component is represented in
multiple models and hence in multiple modules. The extensive interactions among modules cause
problems with both modifiability and integration. If the module that controls turning is integrated with
the module that controls level flight, and a problem is discovered in the data being provided to the
turning module, that same data is probably being accessed by the level flight module. For these
reasons, there were many coupling effects to be considered during integration and maintenance.
The architectural pattern, called 
Structural Modeling
, that resulted from the reconsideration of the
problems of flight simulators will be discussed for the remainder of this chapter. In brief, the pattern
includes an object-oriented design to model the subsystems and controller children of the air vehicle. It
marries real-time scheduling to this object-oriented design as a means of controlling the execution order
of the simulation's subsystems so that fidelity can be guaranteed.
[ Team LiB ]
This PDF file was converted by Atop CHM to PDF Converter free version!  http://www.chmconverter.com/chm-to-pdf/
Addison Wesley : Software Architecture in Practice, Second Edition
183 / 463
VB.NET PDF Convert to Word SDK: Convert PDF to Word library in vb.
VB.NET Tutorial for How to Convert PDF to Word (.docx) Document in VB.NET. using RasterEdge.XDoc.PDF; Convert PDF to Word Document in VB.NET Demo Code.
copy pdf picture to word; how to copy an image from a pdf
VB.NET PDF insert image library: insert images into PDF in vb.net
VB.NET PDF - Add Image to PDF Page in VB.NET. Free VB.NET PDF SDK library for processing PDF image in Visual Studio VB.NET program.
paste image into pdf reader; copy pdf picture
[ Team LiB ]
8.3 Architectural Solution
Figure 8.3
shows a reference model for a flight simulator. The three roles we identified earlier (air vehicle,
environment, and instructor) are shown interacting with the crew and the various cueing systems.
Typically, the instructor is hosted on a different hardware platform from the air vehicle model. The
environment model may be hosted either on a separate hardware platform or with the instructor station.
Figure 8.3. Reference model for flight simulator
The logical division between the instructor station and the other two portions is clear. The instructor
station supports the instructor's control and monitoring of the actions of the crew. The other two portions
perform the simulation. The division between the air vehicle and the environment is not as clear. For
example, if an aircraft launches a weapon, it is logically a portion of the air vehicle until it leaves the
vehicle, at which point it becomes a portion of the environment. Upon firing, the aerodynamics of the
weapon are influenced initially by the proximity of the aircraft. Thus, any modeling of the aerodynamics
must remain, at least initially, tightly coupled to the air vehicle. If the weapon is always considered a
portion of the environment, its modeling involves tight coordination between the air vehicle and the
environment. If it is modeled as a portion of the air vehicle and then handed off to the environment when
fired, control of the weapon needs to be handed from one to the other.
TREATMENT OF TIME IN A FLIGHT SIMULATOR
Recall from Chapter 5
that resource management is a category of tactics to achieve performance goals.
In a real-time simulator, the most important resource to manage is time itself. A flight simulator is supposed
to reflect the real world, which it does by creating time-based real-world behaviors. Thus, when the pilot
in a simulator activates a particular control, the simulator must provide the same response in the same
time as the actual aircraft would. "In the same time" means both within an upper bound of duration after
the event and within a lower bound of duration. Reacting too quickly is as bad for the quality of the
simulation as reacting too slowly.
There are two fundamentally different ways of managing time in a flight simulator—periodic and event-
based—and both of these are used. Periodic time management is used in portions that must maintain
real-time performance (such as the air vehicle), and event-based time management is used in portions
where real-time performance is not critical (such as the instructor station).
This PDF file was converted by Atop CHM to PDF Converter free version!  http://www.chmconverter.com/chm-to-pdf/
Addison Wesley : Software Architecture in Practice, Second Edition
184 / 463
C# Create PDF from Word Library to convert docx, doc to PDF in C#.
A convenient C#.NET control able to turn all Word text and image content into high quality PDF without losing formatting. Convert
cut and paste image from pdf; copy paste image pdf
C# PDF Convert to Word SDK: Convert PDF to Word library in C#.net
key. Quick to remove watermark and save PDF text, image, table, hyperlink and bookmark to Word without losing format. Powerful components
preview paste image into pdf; how to paste a picture into a pdf
Periodic Time Management
A periodic time-management scheme has a fixed (simulated) time quantum based on the frame rate. That
is the basis of scheduling the system processes. This scheme typically uses a non-pre-emptive cyclic
scheduling discipline, which proceeds by iterating through the following loop:
Set initial simulated time.
Iterate the next two steps until the session is complete.
1. Invoke each of the processes for a fixed (real) quantum. Each process calculates its internal
state based on the current simulated time and reports it based on the next period of simulated
time. It guarantees to complete its computation within its real-time quantum.
2. Increment simulated time by quantum.
A simulation based on the periodic management of time will be able to keep simulated time and real time
in synchronization as long as each process is able to advance its state to the next period within the time
quantum allocated to it.
Typically, this is managed by adjusting the responsibilities of the individual processes so that they are
small enough to be computed in the allocated quantum. It is the designer's responsibility to provide the
number of processors needed to ensure sufficient computational power to enable all processes to receive
their quantum of computation.
Event-Based Time Management
An event-based time-management scheme is similar to the interrupt-based scheduling used in many
operating systems. The schedule proceeds by iterating through the following loop:
Add a simulated event to the event queue.
While there are events remaining in the event queue,
- choose the event with the smallest (i.e., soonest) simulated time.
- set the current simulated time to the time of the chosen event.
- invoke a process for the chosen event. This process may add events to the event queue.
In this case, simulated time advances by the invoked processes placing events on the event queue and
the scheduler choosing the next event to process. In pure event-based simulations, simulated time may
progress much faster (as in a war game simulation) or much slower (as in an engineering simulation) than
real time.
Mixed-Time Systems
Returning now to the scheduling of the three portions of the flight simulator, the instructor station is
typically scheduled on an event basis—those events that emanate from the instructor's interactions—and
the air vehicle model is scheduled on a periodic basis. The environment model can be scheduled using
either regime. Thus, the coupling between the air vehicle and the environment may involve matching
different time regimes.
Flight simulators must marry periodic time simulation (such as in the air vehicle model) with event-based
simulation (such as in the environment model, in some cases) and with other event-based activities that
are not predictable (such as an interaction with the instructor station or the pilot setting a switch). Many
scheduling policies are possible from the perspective of each process involved in this marriage.
A simple policy for managing events within a periodically scheduled processor is that periodic processing
This PDF file was converted by Atop CHM to PDF Converter free version!  http://www.chmconverter.com/chm-to-pdf/
Addison Wesley : Software Architecture in Practice, Second Edition
185 / 463
must occur immediately after a synchronization step and complete before any aperiodic processing.
Aperiodic processing proceeds within a bounded interval, during which as many messages as possible
will be retrieved and processed. Those not processed during a given interval must be deferred to
subsequent intervals, with the requirement that all messages be processed in the order received from a
single source.
Communication from the portions of the system managed on an event basis to the portions managed
using periodic scheduling appears as aperiodic and is scheduled as just discussed. Communication from
the portions of the system managed using periodic schedule appears as events to the portions managed
on an event basis.
Given this understanding of managing time in a flight simulator, we can now present the architectural
pattern that handles this complexity. This pattern is for the air vehicle, and so the time management
discussion is from the air vehicle's perspective.
THE STRUCTURAL MODEL ARCHITECTURAL PATTERN
Structural Model is an architectural pattern, as we defined it in Section 2.3
. That is, it consists of a
collection of element types and a configuration of their coordination at runtime. In this section, we present
the Structural Model pattern and discuss the considerations that led to its design. Recall that the air
vehicle model itself may be spread over several processors. Thus, the elements of the air vehicle
structural model must coordinate internally across processors as well as with the environment model and
the instructor portions of the simulation running on (potentially) different processors.
The constituents of the Structural Model architectural pattern are, at the coarsest level, the 
executive
and
the 
application
.
The 
executive
portion handles coordination issues: real-time scheduling of subsystems,
synchronization between processors, event management from the instructor–operator station, data
sharing, and data integrity.
The 
application
portion handles the computation of the flight simulation: modeling the air vehicle. Its
functions are implemented by subsystems and their children.
First we will discuss the air vehicle's executive modules in detail and then return to a discussion of its
application modules.
MODULES OF THE AIR VEHICLE MODEL EXECUTIVE
Figure 8.4
shows the air vehicle structural model with the executive pattern given in detail. The modules
in the executive are the 
Timeline Synchronizer
, the 
Periodic Sequencer
, the 
Event Handler
, and the
Surrogates
for other portions of the simulator.
Figure 8.4. The Structural Modeling pattern of an air vehicle system processor with focus on the
executive
This PDF file was converted by Atop CHM to PDF Converter free version!  http://www.chmconverter.com/chm-to-pdf/
Addison Wesley : Software Architecture in Practice, Second Edition
186 / 463
Timeline Synchronizer
The timeline synchronizer is the base scheduling mechanism for the air vehicle model. It also maintains
the simulation's internal notion of time. The other three elements of the executive—the periodic
sequencer, the event handler, and the surrogates—all must be allocated processor resources. The
timeline synchronizer also maintains the current state of the simulation.
The timeline synchronizer passes both data and control to the other three elements and receives data
and control from them. It also coordinates time with other portions of the simulator. This can include other
processors responsible for a portion of the air vehicle model which have their own timeline synchronizers.
Finally, the timeline synchronizer implements a scheduling policy for coordinating both periodic and
aperiodic processing. For the sake of continuity, precedence is given to the periodic processing.
Periodic Sequencer
The periodic sequencer is used to conduct all periodic processing performed by the simulation's
subsystems. This involves invoking the subsystems to perform periodic operations according to fixed
schedules.
The periodic sequencer provides two operations to the timeline synchronizer. The import operation
requests that the periodic sequencer invoke subsystems to perform their import operation. The update
operation requests that the periodic sequencer invoke subsystems' update operations.
To conduct its processing, the periodic sequencer requires two capabilities. The first is to organize
knowledge of a schedule. By 
schedule
we mean the patterns of constituent invocations that represent the
orders and rates of change propagation through the simulation algorithms realized by the constituents.
The enactment of these patterns essentially represents the passage of time within the air vehicle
simulation in its various operating states. The second capability is to actually invoke the subsystems
through their periodic operations by means of some dispatching mechanism.
Event Handler
The event handler module is used to orchestrate all aperiodic processing performed by subsystems. This
involves invoking their aperiodic operations.
This PDF file was converted by Atop CHM to PDF Converter free version!  http://www.chmconverter.com/chm-to-pdf/
Addison Wesley : Software Architecture in Practice, Second Edition
187 / 463
The event handler provides four operations to the timeline synchronizer: configure (used to start a new
training mission, for example), constituent_ event (used when an event is targeted for a particular
instance of a module), get_outbound_msg (used by the timeline synchronizer to conduct aperiodic
processing while in system operating states, such as operate, that are predominantly periodic), and
send (used by subsystem controllers to send events to other subsystem controllers and messages to
other systems).
To perform its processing, the event handler requires two capabilities. The first capability is to determine
which subsystem controller receives an event, using knowledge of a mapping between event identifiers
and subsystem instances. The second capability is to invoke the subsystems and to extract required
parameters from events before invocation.
Surrogate
Surrogates are an application of the "use an intermediary" tactic and are responsible for system-to-
system communication between the air vehicle model and the environment model or the instructor station.
Surrogates are aware of the physical details of the system with which they communicate and are
responsible for representation, communication protocol, and so forth.
For example, the instructor station monitors state data from the air vehicle model and displays it to the
instructor. The surrogate gathers the correct data when it gets control of the processor and sends it to the
instructor station. In the other direction, the instructor may wish to set a particular state for the crew. This
is an event received by the surrogate and passed to the event processor for dispatching to the
appropriate subsystems.
This use of surrogates means that both the periodic scheduler and the event handler can be kept
ignorant of the details of the instructor station or the platform on which the environment model is
operating. All of the system-specific knowledge is embedded in the surrogate. Any change to these
platforms will not propagate further than the surrogate in the air vehicle model system.
MODULES OF THE AIR VEHICLE MODEL APPLICATION
Figure 8.5
shows the module types that exist in the application subpart of the air vehicle structural model.
There are only two: the 
Subsystem Controller
and the 
Controller Child
. Subsystem controllers pass data
to and from other subsystem controller instances and to their children. Controller children pass data only
to and from their parents, not to any other controller children. They also receive control only from their
parents and return it only to their parents. These restrictions on data and control passing preclude a
controller child from passing data or control even to a sibling. The rationale for this is to assist integration
and modifiability by eliminating coupling of a child instance with anything other than its parent. Any effect
of modification or integration is mediated by the parent subsystem controller. This is an example of the
use of the "restrict communication" tactic.
Figure 8.5. The application module types
This PDF file was converted by Atop CHM to PDF Converter free version!  http://www.chmconverter.com/chm-to-pdf/
Addison Wesley : Software Architecture in Practice, Second Edition
188 / 463
Subsystem Controller
Subsystem controllers are used to interconnect a set of functionally related children to do the following:
Achieve the simulation of a subsystem as a whole.
Mediate control and aperiodic communication between the system and subsystems.
They are also responsible for determining how to use the capabilities of their children to satisfy trainer-
specific functionality such as malfunctions and the setting of parameters.
Because the Structural Model pattern restricts communication among controller children, a subsystem
controller must provide the capability to make logical connections between its children and those of other
subsystems. Inbound connections supply inputs produced outside of the subsystem that the subsystem's
children need for their simulation algorithms. Outbound connections satisfy similar needs of other
subsystems and of surrogates. These connections appear as sets of names by which a subsystem
controller internally refers to data considered to be outside of itself. When such a name is read or written,
the appropriate connections are assumed to be made. How the connections are actually made is
determined later in the detailed design and is a variation point of the pattern (see Chapter 14
, Product
Lines, for a discussion of variation points). In addition to making connections between its children and
those of other subsystems, the subsystem controller also acts as an intermediary among its own children
since restricting communication means that they are not allowed to directly communicate among
themselves.
As we mentioned, a flight simulator can be in one of several states. This is translated through the
executive to a particular executive state. The executive then reports its current state to the subsystem
controller. The two states that are relevant here are 
operate
and 
stabilize
. The operate state instructs the
subsystem controller to perform its normal computations relevant to advancing the state of the simulation.
The stabilize state tells the subsystem controller to terminate its current computation in a controlled
fashion (to prevent the motion platform from harming the crew through uncontrolled motion) as follows:
Retrieve and locally store the values of inbound connections under the direct control of an
executive. Such a capability addresses issues of data consistency and time coherence.
Stabilize the simulation algorithms of its children under the control of executive instances and report
whether it considers the subsystem as a whole to be currently stable.
Subsystem controllers 
must
be able to do the following:
Initialize themselves and each of their children to a set of initial conditions in response to an event.
Route requests for malfunctions and the setting of simulation parameters to their children based on
knowledge of child capabilities.
Finally, subsystem controllers may support the reconfiguration of mission parameters such as armaments,
cargo loads, and the starting location of a training mission. Subsystem controllers realize these
capabilities through periodic and aperiodic operations made available to the periodic sequencer and
event handler, respectively.
Subsystem controllers must support the two periodic operations—update and import—and may
support two others (which are aperiodic)—process_event and configure.
Update
The update operation causes the subsystem controller to perform periodic processing appropriate to the
current system operating state, which is provided as an input parameter. In the 
operate
state, the update
operation causes the subsystem controller to retrieve inputs needed by its children by means of inbound
connections, to execute operations of its children in some logical order so that changes can be
This PDF file was converted by Atop CHM to PDF Converter free version!  http://www.chmconverter.com/chm-to-pdf/
Addison Wesley : Software Architecture in Practice, Second Edition
189 / 463
Documents you may be interested
Documents you may be interested