Physical Architecture 1

http://slideplayer.com/slide/701864/
 Create a Functional Architecture

FIGURE 5-24. From Multiple Scenarios to an Integrated Architecture of Behaviors and Functions.
Here we show a complete functional architecture that includes the interactions from all the individual
scenarios as well as the interactions between the scenarios. The boxes are functions, the ovals are inputs,
commands and outputs, and the circles and lines represent the logical execution flow of the functions. The
"LP" flow circle represents an execution loop and "LE" represents the loop exit (condition when the
execution flow exits the loop). (IR is infrared; GPS is Global Positioning System.)
 Define a Physical Architecture
1) To define a Physical Architecture:
- Determine the physical elements or partitions
- Allocate the functional architecture to these physical elements
- Establish the interfaces between the system's physical elements
2) These steps aren’t sequential, but are done in parallel
3) As with the functional architecture, architects generally define the
physical architecture in multiple levels of detail
4) The process apportions the system architecture down to the
configuration item level, at which point the development teams
begin their designs
 Define a Physical Architecture

https://www.hilarispublisher.com/open-access/configuration-selection-process-review-2169-0316-1000216.pdf
 Define a Physical Architecture

https://www.hilarispublisher.com/open-access/configuration-selection-process-review-2169-0316-1000216.pdf
 Define a Physical Architecture

https://www.hilarispublisher.com/open-access/configuration-selection-process-review-2169-0316-1000216.pdf
 Defining a Physical Architecture
1) Configuration Item
a) The lowest level of design to which the system is managed
b) The level at which the project buys or uses an existing item,
or decides to develop it
c) It’s the level the hardware & software teams start to design
2) Examples
a) Complex software development
b) Developing a system with COTS items
Configuration Item in a Physical Architecture

http://www.chambers.com.au/glossary/configuration_item.php
 Developing a system with COTS items
1) The partitioning should stop after we define:
a) This item as a configuration item, or physical component
b) The interfaces between this component and others in
the architecture
c) The functions this component will perform
d) Functional and other requirements the component must
meet

COTS: an existing, non developed item

commercial-off-the-shelf
 Configuration Item in SE V Model

https://ops.fhwa.dot.gov/f
reewaymgmt/publications/
cm/handbook/chapter7.ht
m
 Context Diagram
With system's physical components and its physical links to external systems
 Create the Physical Partitions
1) The physical architecture partitions a System of Interest
into its subparts or components
2) The physical components are the system resources that
perform its functions: hardware, software, facilities,
people, or procedures.
3) We have functions with names that begin with a verb,
but the physical components are represented by a noun:
what or who is performing a function
4) Architects typically work with two types of
physical architectures: generic and instantiated.
Generic Physical Architecture
Fig. 5.28
“Reference”
or “Platform”
Architecture
Instantiated Physical Architecture
Fig. 5.29
“Product”
or “Solution”
Architecture
 Create the Physical Partitions
1) We decide what functions of the hardware, software, people,
process, or infrastructure components should do.
2) This step is essential, because it defines the physical solution to
build and the interfaces within physical components.
The physical solution drives the solution cost, schedule,
performance, and associated risks
3) This step may also require a lot of iteration as we modify the
functional architecture to more efficiently fit a physical solution.
Trade-offs occur among solutions until we find the best fit.
4) All functions must be allocated to some physical component,
if we want to understand how each function gets done
5) If a function is allocated to multiple physical components,
we should decide how to split the function into many subfunctions,
so we can allocate each subfunction to a single component.
 Allocate Functions to Physical Components

• Sometimes splitting a function handled by more than one physical component

doesn't make sense. For example, a system may have a function,
Provide information to the user, that puts system responses on a display for viewing.
• Two or more physical components may cover this function - for example, a display
monitor and a software application: it may NOT be cost-effective to split this function
into 2 functions
• Distributed systems are another case in which several physical components may do
the same function
Allocate Functions to Physical Components
Many functions to a single component
Reasons to put several functions
on a single physical component:
• Functions are related or handle similar tasks
• Performance will improve if functions
combine in a single component
• Existing components (commercial-off-the-
shelf or otherwise) cover several Functions
• Functions are easier to test
• Technology risk is lower
• Interfaces are less complex
• Allocation meets future performance
requirements
• It matches potential future technology
Fig. 5.31
Several Functions on a Single Component

/
https://bterry6693.wordpress.com/2014/09/22/theres-an-app-for-that-the-importance-of-smartphone-applications
 Allocate Functions to Physical Components
Components without functions

Reasons for is a physical component

without function:
• Reusing a legacy system
• Use a reference architecture
• Use a successful platform
architecture
• It’s cheaper and quicker to keep it
• A possible future capability
Physical and Functional Elements
Trade Studies to allocate Functions to Components
Morphological Box
 Physical Hierarchy for Firesat

It’s easy to note the traceability in the system above

 Defining External Interfaces for a system
We decompose the space element into the ways that we can implement it by selecting:
• Which type of component or element will handle the function?
Hardware, software, infrastructure, or people and processes?
• What kind of hardware will we use, including commercial-off-the-shelf (COTS) versus
developed; distributed versus centralized, and so on?
• What type of software will we use-including COTS versus developed, handled in the
client versus the server, using a single processor versus distributed processors, etc
• What are the technology limits of the potential implementations?
Throughput capacities - Delay times - Distance limits
• What are the interface's locations or environments?
• What protocols or standards are being used? - Transmission Control Protocol/Internet
Protocol (TCP/IP) or Open Systems Interconnection (OSI) (7-layer) reference model -
Data formats - Data bus standard, e.g., RS-232, Mil-Std-1553
• What is the information, signal, data, or energy being transferred across the interface
(including type, amount, and frequency)?
These details should be specified in the functional architecture, as part of the definition
of information moving from one function (performed by one component)
to another function (performed by another component)
Creating Interfaces
Concept used to a Development Architecture
Model includes functions:
- Design Engineering
- Logistics and Support
- Manufacturing
- Program Management
- Systems Engineering
- Specialty Engineering
- Software Engineering
- Test
Each Function depicts:
- Inputs and outputs
- Dependencies
- Deliverable products

http://slideplayer.com/slide/701840/
 Classwork

1) Construa uma hierarquia física para o seu sistema,

com rastreabilidade
2) Construa uma carta morfológica para os elementos desta
arquitetura física com várias opções de escolha para cada elemento.
3) Escolha e justifique sua escolha para cada elemento baseando sua
escolha em aspectos técnicos, de custo, de cronograma, ou de
embargo tecnológico.