page 1 building reliable component-based systems chapter 17 - architectural support for reuse...
Post on 22-Dec-2015
216 views
TRANSCRIPT
Page 1Building Reliable Component-based Systems Chapter 17 - Architectural Support for Reuse
Chapter 17Chapter 17
Architectural Support for ReuseArchitectural Support for Reuse
Page 2Building Reliable Component-based Systems Chapter 17 - Architectural Support for Reuse
OverviewOverview
Industrial Automation Systems
The Motivation for a Platform
The Architecture
Developing a Domain Specific Application
Page 3Building Reliable Component-based Systems Chapter 17 - Architectural Support for Reuse
Industrial Automation SystemsIndustrial Automation Systems
Highly specialized, independent, and incompatible hardware and software system solutions.
A flexible combination of basic hardware and software components, communications infrastructure, and application components.
Page 4Building Reliable Component-based Systems Chapter 17 - Architectural Support for Reuse
The 6-layer Model of a Technical ProcessThe 6-layer Model of a Technical Process
Group Control Level
ProductionManagement Level
Process Level
Field Level
EnterpriseLevel
Process Control Level
Page 5Building Reliable Component-based Systems Chapter 17 - Architectural Support for Reuse
The Motivation for a PlatformThe Motivation for a Platform
Envisioned seamless link between front-end business processes and plant control processes:
Motivations for a large global company to invest into the development of a “single” platform.
Avoidance of parallel developments in different business segments.
Harmonization of the diversity of ‘legacy’ automation platforms acquired through company mergers or resulting from previous parallel developments.
Adoption of product line business strategies (i.e. pursuing a system family concept both within and across vertical market segments).
Implicit expectation of a reuse payoff.
Page 6Building Reliable Component-based Systems Chapter 17 - Architectural Support for Reuse
The ArchitectureThe Architecture
AspectObject, Object Type, Aspect and Aspect Type.
Aspect System
A collection of Aspect Types for a certain context or purpose.
Domain-related reuse.
AspectSystemObject
Some Aspect-specific software is needed.
(binary) Software component; Microsoft COM component following specific rules
The basic set of ASOs distributed with the AIP contains functionality for alarming, event handling etc.
Page 7Building Reliable Component-based Systems Chapter 17 - Architectural Support for Reuse
AspectObjectsAspectObjects
The most central type of entity in the model
AspectObjects model physical objects
E.g. a specific valve in a dairy (“FIC 201 Valve”)
Does not contain any data
Related data is carried by its Aspects
AspectObjectAspect
Aspect Aspect
Aspect
Page 8Building Reliable Component-based Systems Chapter 17 - Architectural Support for Reuse
AspectAspect
Encapsulates a subset of the data related to an AspectObject
Different types of electronic information (e.g. documents)
<<Domain Object>>Valve
<<Aspect Object>>Valve
<<Aspect>>Control
<<Aspect>> Mechanical
Drawing
<<Aspect>> Maintenance Instructions
<<Aspect>>OperatorGraphics
<<is modeled by>>
<<Aspect>>Operation
Report
1 1 1 1 1
Page 9Building Reliable Component-based Systems Chapter 17 - Architectural Support for Reuse
Aspect TypesAspect Types
Defines how the data in an Aspect is used
In a “Mechanical Drawing” Aspect, the data is opened with AutoCad
In a “Maintenance Instructions” Aspect, the data is opened with Acrobat Reader
Reuse!+Name : string(idl) = "Mechanical Drawing"+Action : string(idl) = "Open With AutoCad"
Aspect Type
+Data : <unspecified> = 10110100010110010110...
Aspect
Page 10Building Reliable Component-based Systems Chapter 17 - Architectural Support for Reuse
Aspect Types, cont.Aspect Types, cont.
+Name : string(idl) = "Mechanical Drawing"+Action : string(idl) = "Open With AutoCad"
Aspect Type
+Data : <unspecified> = 10110100010110010110...
Aspect
Page 11Building Reliable Component-based Systems Chapter 17 - Architectural Support for Reuse
Object TypesObject Types
Models the type of an AspectObject
The type of “FIC 201” is “Valve”
Defines what Aspect Types an AspectObject can have
A “Valve” can have a “Mechanical drawing” etc.
Reuse!
Page 12Building Reliable Component-based Systems Chapter 17 - Architectural Support for Reuse
Object Types, cont.Object Types, cont.
+Name : string(idl) = "Valve"+Aspects : Aspect Type = "Mechanical Drawing", ...
Object Type
+Name : string(idl) = "FIC 201"+Aspects : Aspect
AspectObject
Page 13Building Reliable Component-based Systems Chapter 17 - Architectural Support for Reuse
StructuresStructures
Models a structure
Location structure
Functional structure
Batch structure
...
Typically, each AspectObject is part of several structures
Page 14Building Reliable Component-based Systems Chapter 17 - Architectural Support for Reuse
Structures, cont.Structures, cont.
Page 15Building Reliable Component-based Systems Chapter 17 - Architectural Support for Reuse
Structures, cont.Structures, cont.
Location structure
Enables browsing through the physical layout
See what valves are physically connected to a pipe
Functional structure
Enables browsing through the functional layout
See what control units are connected to a valve
Page 16Building Reliable Component-based Systems Chapter 17 - Architectural Support for Reuse
Physical viewPhysical view
Client-server system
Freedom to choose number of servers
Scalability
Reliability
Freedom to choose number of services
Page 17Building Reliable Component-based Systems Chapter 17 - Architectural Support for Reuse
Physical view, cont.Physical view, cont.
WP host
SH C
WP
Server host
ASM
SH A
SH B
WP host
SH C
WP
SH A
SH B
SP A
SP C
Server host
ASM
SP A
SP B
SP C
Server host
ASM
SP A
SP B
SP C
Server/WP host
ASM
SP C
SH C
WP
SH A
SH B
Controller Controller Controller Controller
station network
Controller network
Service group A
Service group B
Service group C1
Service group C2
SP: service provider
SH: service handler
ASM: Afw Service Manager
WP: workplace
Page 18Building Reliable Component-based Systems Chapter 17 - Architectural Support for Reuse
Developing a Domain Specific Application Developing a Domain Specific Application
Jacobson et al. have introduced the distinction between an application system and a component system:
Reusing a single component is usually insufficient.
Requires the reuse of a set of components.
A set of components must be reused to obtain the alarm handling functionality.
Page 19Building Reliable Component-based Systems Chapter 17 - Architectural Support for Reuse
4-Layer Representation4-Layer Representation
Application system layer:
Offers a coherent set of use cases to some end users.
The business-specific:
Layer several component systems used by the application engineer.
The middleware layer:
Independent of particular types of business
GUI builders, database management systems, etc.
The system software layer:
Operating systems.
Indistinct boundaries between itself and middleware.
Page 20Building Reliable Component-based Systems Chapter 17 - Architectural Support for Reuse
AIP Reuse Hierarchy AIP Reuse Hierarchy
W2k
AIP base infrastructure
AIP base ASOsproject specific
ASOs
AIP base Servicesproject specific
Services
AIP built-in admin Aspect Types
project specific Aspect TypesAIP built-in
general-purpose
Aspect Types
AIP built-in admin Object
Types
project specific Object Types
AIP built-in general-
purpose Object Types
domain specific
Aspect Types
domain specific
Object Types
domain specific templates and patterns project specific templates and patterns
enablers
engineering guidelines and
toolsAIP library concept
AIP export/import
OT inheritance
AIP export/import
AT inheritance
COM
VC++
configuration
3rd party applications
Page 21Building Reliable Component-based Systems Chapter 17 - Architectural Support for Reuse
Some Words of Caution Some Words of Caution
Possible risks:
Only relying on a platform, not having a reuse-driven process or product line practice with a top-down and planned approach to reuse will not succeed.
Requirements management:
Requirements elicitation, prioritisation and trade-offs across products, domains, and organizational units are extremely complex.
Bugs in a released version