Download as PDF, PPTX
![Re inventing the RoleRe‐inventing the Role
Courtesy: Facebook comCourtesy: Facebook.com
Evolution of Programming Languages indicate
increasing levels of abstraction.
Software Defined Everything!
Significance moves to structures and organize
them :- Architecture
Architecture plays a key role in Innovations
Multi-skilled and Ability to bring experience to Multi skilled and Ability to bring experience to
table.
12 Essential Skills [1]](https://image.slidesharecdn.com/software-roleinsystemsandtheirarcv1-180118084603/75/Software-Role-in-Systems-and-Architectures-3-2048.jpg)
![Tools for solution spaceTools for solution space
Architecture Patterns – POSA 1 and 2 [2]
Architecture Tactics – Software Architecture in
Practice [3]
Design Patterns – GoF Design Patterns [4]
Estimation
Data structures and Algorithms in STL [5]
Is the solution
stimation
Open Source /COTS/Reuse from within
Is the solution
suitable for the
problem
Reference ArchitecturesYESNO YESNO](https://image.slidesharecdn.com/software-roleinsystemsandtheirarcv1-180118084603/75/Software-Role-in-Systems-and-Architectures-27-2048.jpg)
![Architecture Description – Addressing
View Point of Development Team
1. Object Model &
Toolbox
2 Engineering2. Engineering
scenario
definition and
view
3
3. Animation
Framework for
scene play
4
4. Basic
communication
engine to
interface withLayered View : Describes the decomposition
1 2
interface with
external
simulation
y p
at a public level and interfaces
The principles based on SISO standards, the graphical layer, and the
player layer BOM Base Object Model [13]player layer. BOM – Base Object Model [13]
Detailed description of Architecture and Design [14] and Source Code
[15]](https://image.slidesharecdn.com/software-roleinsystemsandtheirarcv1-180118084603/75/Software-Role-in-Systems-and-Architectures-32-2048.jpg)
Uploaded byAbhilash Gopalakrishnan
Software - Role in Systems and Architectures
The document discusses the evolving role of software architects in systems with increasing software intensity, highlighting the significance of architecture in innovation and addressing stakeholders' needs. It covers IEEE 42010 standards, the business cycle of architecture, and the importance of multi-disciplinary collaboration in systems engineering. Key aspects include architecture definitions, quality attributes, the architecture business cycle, and tools for problem and solution spaces.
More Related Content
Similar to Software - Role in Systems and Architectures
Software - Role in Systems and Architectures
- 1. Software – Rolein Systems andSoftware – Role in Systems and their Architectures Talk at Software Architects Meetup 1 Oct 20161 Oct 2016 Abhilash Gopalakrishnan Principal EngineerPrincipal Engineer, Electrical Products Distribution Automation, India Development Center ABB Global Industries & Services Pvt. Ltd.ABB Global Industries & Services Pvt. Ltd.
- 2. AgendaAgenda • Re‐inventing the Role of Software Architect • Systemsand Increasing Software IntensitySystems and Increasing Software Intensity • IEEE 42010 standard • Architecture Business Cycle • Problem Space and Solutions spaceProblem Space and Solutions space • Architecture Definition
- 3. Re inventing theRoleRe‐inventing the Role Courtesy: Facebook comCourtesy: Facebook.com Evolution of Programming Languages indicate increasing levels of abstraction. Software Defined Everything! Significance moves to structures and organize them :- Architecture Architecture plays a key role in Innovations Multi-skilled and Ability to bring experience to Multi skilled and Ability to bring experience to table. 12 Essential Skills [1]
- 4. SystemsSystems • Systems forma chain involving h i l l t i l l t i i ti &– mechanical, electrical, electronics, communication & software entities. – Involves multiple interfaces across various subsystemssubsystems – Interfaces with real world! – The lifecycle of these systems normally longer. Range from embedded systems for control or– Range from embedded systems for control or automotive applications, telecommunication, business applications like banking. The complexities and size aspects of systems vary.The complexities and size aspects of systems vary. For someone from ISRO it is Earth as a System, For someone from automobile industry it is about vehicular systems like Anti Braking System (ABS) F f I d t i l C t l S t it iFor someone from Industrial Control Systems it is SCADA or DCS. We limit our discussion to more commercial Distributed Control System applications like industrial control systems. Systems span multiple disciplines
- 5. Example : Asian Paints Distribution Network Paint dispensing machines integrated withintegratedwith Software based HMI found at Asian Paint dealerships Courtesy: Asian Paints Dealership Systems have become an invisible part of our lives!
- 6. Example: Industrial ControlsystemsExample: Industrial Control systems Remote Access Pl t N t kPlant Network Control Zone Field Instrumentation Involve wide variety of subsystems, interfaces and lifetimes more than 15 years
- 7. Systems and ITApplicationsSystems and IT Applications Characteristic Systems IT Applications Time to market 1 Year and reducing Much less even in the rangeTime to market 1 Year and reducing Much less, even in the range of months Target Market Specific market segments driven by reliability and cost factors Targeted at applications more to improve productivityreliability and cost factors more to improve productivity. Expected Lifetime 10-30 years 1-5 years Relevant owners Phase wise owners from operator, engineer end customer Owners could vary across projectsengineer, end customer, decommissioning engineer projects. Legacy support/Backward Strong requirements due to huge investments required Weak requirements due to the fact that an ITsupport/Backward Compatibility Requirements investments required the fact that an IT implementation could reduce current operating cost. Shutdown Shutdown only permitted as part of Shutdown is permitted withinShutdown permitted Shutdown only permitted as part of planned maintenance. Else could lead to losses Shutdown is permitted within tolerance benchmarks. Safety Critical Yes considering human lives and Few implementations areSafety Critical Yes, considering human lives and huge investments to be protected Few implementations are safety critical, but not all Further Systems interface with real world!
- 8. AgendaAgenda • Alignment to the Program • Systemsand Increasing Software IntensitySystems and Increasing Software Intensity • IEEE 42010 standard • Architecture Business Cycle • Problem Space and Solutions spaceProblem Space and Solutions space • Architecture Definition
- 9. Software Intensive SystemsSoftware Intensive Systems SbSoftware • Systems can be classified software intensive when Software Mechanical Electronics intensive when, – 40‐50 % of subsystems constitute software Communication • Examples – Vehicular Systems it y could even be 50% Software components I d i l C l– Industrial Control Systems is close to 40%
- 10.
- 11.
- 12. Telecommunication: growing intensity of software d d fHardware and Software intermingled/ Closed Architecture Ei ti S it h A hit tExisting Switch Architectures Flow Controller Software would handle flow New Protocol introduced Safety and Security Software Defined Network based Architecture y y Software plays a key role in innovation
- 13. AgendaAgenda • Alignment to the Program • Systemsand Increasing Software IntensitySystems and Increasing Software Intensity • IEEE 42010 standard • Architecture Business Cycle • Problem Space and Solutions spaceProblem Space and Solutions space • Architecture Definition
- 14. IEEE 42010 OnSoftware ArchitectureIEEE 42010 – On Software Architecture • A system is built to address• A system is built to address the needs concerns goals and objectives of its stakeholders (owners) ARCHITETCURAL ELEMENT INTER ELEMENT RELATIONSHIP REALIZES • The architecture of system comprises of its architectural elements and their interrelationships ELEMENT RELATIONSHIP COMPRISES COMPRISES p • Architecture can be documented in Architecture Description • An Architecture Description ARCHITETCTURE SYSTEM HAS AN ADDRESS NEEDSCAN BE DOCUMENTED IN • An Architecture Description documents architecture for the stakeholders and demonstrates to them that it h t th i d ARCHITETCURAL DESCRIPTION STAKEHOLDER CAN BE DOCUMENTED IN DOCUMENTS ARCHITECTURE FOR it has met their needsFOR Architecture address needs of stakeholders
- 15. Architecture Quality AttributesArchitecture‐Quality Attributes Attribute Name Industrial Control System Vehicular Systems Reliability High Reliability – Probably of failure is High Reliability – Probably ofReliability High Reliability Probably of failure is 10‐9 High Reliability Probably of failure is 10‐9 Safety Safety important and applies more to certain types of Process ‐ IEC 61508 SIL ISO 26262 Safety Integrity level for Automobilescertain types of Process IEC 61508 SIL /ANSI/ISA‐84.01‐199 level for Automobiles Availability High Availability and Only Planned Redundancy used both asAvailability High Availability and Only Planned Shutdown. Redundancy used Redundancy used both as node as well as communication paths. Based on application Security High Security needs based on zones Security capabilities exist. Used or not used based on application Performance Deterministic Response expected. Hard Real time in control and protection. Ranges between 1 micro second to 1 millisecond precision and Determinism expected. Differs between application For example Power Train and Chasis are hard real time andsecond to 1 millisecond precision and 3ms‐ 20 ms time to respond. Chasis are hard real time and Telematic HMI soft real time Reliability & Safety are at most importance
- 16. AgendaAgenda • Alignment to the Program • Systemsand Increasing Software IntensitySystems and Increasing Software Intensity • IEEE 42010 standard • Architecture Business Cycle • Problem Space and Solutions spaceProblem Space and Solutions space • Architecture Definition
- 17.
- 18. ViewPoints and ViewsViewPointsand Views "W h t b th t h t"We have to remember that what we observe is not nature in itself, but nature exposed to our method of q estioning “ Werner Heisenbergquestioning.“ -Werner Heisenberg Courtesy: Wikipedia – Elephant and blind men Architect can see the elephant as a whole
- 19. Stakeholders in Industrial Control Systems Operational Decommission • Systemintegrators Factory Acceptance Test Site Acceptance Test Decommission System integrators • System Architects and Designers • Product Managers • Control Engineers G hi D l E i Design & Engineering Acceptance Test • Graphics Development Engineers • Communication Engineers • Testing Engineers doing Factory Acceptance Test (FAT)Specification Engineering • Site Acceptance Test Engineers • Commissioning Engineers • Operators • Decommissioning Engineers• Decommissioning Engineers It is a challenge to even identify all needs
- 20. Significance of ArchitectureSignificance of Architecture RuntimeViewD l Vi • As a vehicle for Runtime ViewDevelopment View communication among stakeholders • Manifestation of earliest design decisions about ta system • Transferable, reusable b i fabstraction of a system Implementation View Deployment ViewImplementation View p y
- 21. AgendaAgenda • Alignment to the Program • Systemsand Increasing Software IntensitySystems and Increasing Software Intensity • IEEE 42010 standard • Architecture Business Cycle • Problem Space and Solutions spaceProblem Space and Solutions space • Architecture Definition
- 22. The Pivotal roleof Architect Solution The Pivotal role of Architect Problem Solution Space Software Space Requirements Analysis So t a e Design Analysis Architecture Definition Architecture Definition Architect is a stakeholder’s person!
- 23. Architect’s Involvement in Development D th fi l t fDepth of involvement of architect could vary across phases in the life cycle. Architect uses his programming skills to build nt‐‐> demonstrators showing how requirements are met nvolvemen ts n/Test epth of In quirement sign nstruction egration cceptance Time ‐‐> D Req Des Con Inte Ac Time ‐‐> Architect is a developer’s person!
- 24. AgendaAgenda • Alignment to the Program • Systemsand Increasing Software IntensitySystems and Increasing Software Intensity • IEEE 42010 standard • Architecture Business Cycle • Problem Space and Solutions spaceProblem Space and Solutions space • Architecture Definition
- 25. Architecture DefinitionArchitecture Definition A hiD i i• Architecture Description is a key deliverable of the Architecture Definition Architecture Description • Goals and System Objectives • Goals and Objectives of System are documented in consultation with • Development Environment d d f in consultation with stakeholders • Architecture Description D t t h th • Hardware and Software Environment Demonstrates how the goals and objectives are achieved using a • Solution: Achieving the Goals and System Objectives candidate architecture Problem Space Solution Space
- 26. Tools for ProblemspaceTools for Problem space • We need a different view point and view defined based on Runtime View stakeholders! • Safety & Security are perspectives D l ViDevelopment View ViewPoints & Views help communicate better!
- 27. Tools for solutionspaceTools for solution space Architecture Patterns – POSA 1 and 2 [2] Architecture Tactics – Software Architecture in Practice [3] Design Patterns – GoF Design Patterns [4] Estimation Data structures and Algorithms in STL [5] Is the solution stimation Open Source /COTS/Reuse from within Is the solution suitable for the problem Reference ArchitecturesYESNO YESNO
- 28. A Case Studyof Architecture DefinitionA Case Study of Architecture Definition Systems Visualization Platform
- 29. User story 1:‐Ability to define user scenario User Profile Useris product manager (Advanced knowledge of industrial automation components.) Background The user is familiar of objects like HMI, Controller, Process Model. The user tries to document a requirement . The user would need this information be t d h bl d t bl b th llstored, shareable and executable by some other colleagues. Objective Able to position, instantiate the elements in a visual pane, connect them and define the sequence. Narrative The user should be able to define the connections between these elements using easy connectors. The user should be able to define the sequence of actions in the workflow. These aspects need to be stored file format C fAcceptance Criteria 1. Elements HMI, Controller, Process Model are available and visible for instantiation 2. Elements can be dropped into editor pane and positioned 3 Elements can be connected together using communication elements3. Elements can be connected together using communication elements 4. The topology and messages and their sequences can be described 5. The contents of the editor can be saved as a file and stored. 6. The contents are loaded and checked if they contain the full description d l t ti dand elements, connections and sequences.
- 30. Architecture Definition :AppliedArchitecture Definition :‐ Applied • Create, Save and Play Scenarios communication Architecturally Significant Use Cases Scenarios, communication with simulation system l i i h • Qt/.NET decision, Communication Stack decision Applying right patterns, tactics and arrive at Candidate Architecture decision • Systems Explorer framework Guidance and Implementation
- 31. Tools for solutionspace : AppliedTools for solution space :‐ Applied Architecture Patterns –Reflection, Layers Architecture Tactics – Usability Is the solution Design Patterns – Factory Method, Singleton Is the solution suitable for the problem Data structures and Algorithms – XML Parsing YES Open Source – Qt framework YES p Reference Architectures – ACE Framework
- 32. Architecture Description – Addressing View Point of Development Team 1. ObjectModel & Toolbox 2 Engineering2. Engineering scenario definition and view 3 3. Animation Framework for scene play 4 4. Basic communication engine to interface withLayered View : Describes the decomposition 1 2 interface with external simulation y p at a public level and interfaces The principles based on SISO standards, the graphical layer, and the player layer BOM Base Object Model [13]player layer. BOM – Base Object Model [13] Detailed description of Architecture and Design [14] and Source Code [15]
- 33. Architecture Description – Addressing View Point of Product Manager 1. Visualization Toolbox– WhatToolbox What components available 2 H ill2. How will a scenario look like? 3 How can we3. How can we specify sequence of actions? 4 H4. How can we save the scenario? Automation View: Product Managers
- 34. Scenario Visualization TodayScenario Visualization‐Today Editor Visualizer
- 35. Documenting Key TechnicalDecisionsDocumenting Key Technical Decisions I i i Date and Time Subject/Problem D i ti It is important to keep note of technical decisions Description Assumptions Alternatives Decision/Solution Description Rationale Ri kRisks Participants Implications Technical Decisions Document
- 36.
- 37. ReferencesReferences 1. Dave Hendricksen,"12 Essential Skills for Software Architects", 2011 2. Pattern Oriented Software Architecture Volume 1 and 2 (POSA) 3 A hit t f O S A li ti3. Architecture of Open Source Applications 4. Len Bass , Paul Clements , Rick Kazman “Software Architecture In Practice” – Second Edition Apr 19, 2003 5. Erich Gamma , Richard Helm , Ralph Johnson, John Vlissides “Design Patterns: El t f R bl Obj t O i t d S ft ” N b 10 1994Elements of Reusable Object-Oriented Software” November 10, 1994 6. Mark Nelson, "C++ Programmer's Guide to the Standard Template Library" December 1995 7. Nick Rozanski and Eóin Woods “Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives (2nd Edition)” Nov 4, 2011 8. Erich Gamma , Richard Helm , Ralph Johnson, John Vlissides “Design Patterns: Elements of Reusable Object-Oriented Software” November 10, 1994 ,ISBN978- 0201633610 9. NIST SP 800-82, Guide to Industrial Control Systems (ICS) Security 10. European Commission & US National Science Foundation "Workshop Report and Recommendations - Engineering Software -Intensive Systems” –22-23 May 2004 11. Dr TV Gopal “Systems Engineering Essentials” , 27 March 2012Gopa Sys e s g ee g sse a s , a c 0 12. IEEE Magazine, “NextGen Vehicular Systems” , June 2012 13. Applications of Software Defined Networks in Industrial Automation – An Architectural analysis – Abhilash Gopalakrishnan 14 Requirements Engineering Visualization Platform Architecture and Experiences14. Requirements Engineering Visualization Platform- Architecture and Experiences – Abhilash Gopalakrishnan, Abhinna Biswal, Ashoka Shyamaprasad 2012. 15. SISO Standards 16. Scenario Visualization Source Code or in GitHub ViewpublicationstatsViewpublicationstats