CPSC 875 John D. McGregor Reference Architectures C9.

Slides:



Advertisements
Similar presentations
Automotive Embedded System Development in AUTOSAR
Advertisements

Overview What is the National ITS Architecture? User Services
Applying the SOA RA Utah Public Safety ESB Project Utah Department of Technology Services April 10, 2008 Prepared by Robert Woolley.
Using UML, Patterns, and Java Object-Oriented Software Engineering Royce’s Methodology Chapter 16, Royce’ Methodology.
Architecture Modeling and Analysis for Embedded Systems Oleg Sokolsky CIS700 Fall 2005.
Software Architecture Design Instructor: Dr. Jerry Gao.
REAL-TIME SOFTWARE SYSTEMS DEVELOPMENT Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
CS 432 Object-Oriented Analysis and Design
© 2006 Pearson Addison-Wesley. All rights reserved2-1 Chapter 2 Principles of Programming & Software Engineering.
The Software Product Life Cycle. Views of the Software Product Life Cycle  Management  Software engineering  Engineering design  Architectural design.
Chapter 10: Architectural Design
Jeju, 13 – 16 May 2013Standards for Shared ICT HIS – Smart Grid Karen Bartleson, President, IEEE Standards Association Document No: GSC17-PLEN-72 Source:
Software Architecture premaster course 1.  Israa Mosatafa Islam  Neveen Adel Mohamed  Omnia Ibrahim Ahmed  Dr Hany Ammar 2.
© 2006, Cognizant Technology Solutions. All Rights Reserved. The information contained herein is subject to change without notice. Automation – How to.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 18 Slide 1 Software Reuse 2.
Chapter 10 Architectural Design
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 18 Slide 1 Software Reuse.
Software Engineering Muhammad Fahad Khan
Software Reuse Prof. Ian Sommerville
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 18 Slide 1 Software Reuse.
Standards John D. McGregor. But first… SECIE-Safety-in-Software-and-Human- Intensive-Systems-Leveson-brief.pdf.
REAL-TIME SOFTWARE SYSTEMS DEVELOPMENT Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
-Nikhil Bhatia 28 th October What is RUP? Central Elements of RUP Project Lifecycle Phases Six Engineering Disciplines Three Supporting Disciplines.
Lead the Way APTA Transit Standards Development “BUS RAPID TRANSIT”
1 COSC 4406 Software Engineering COSC 4406 Software Engineering Haibin Zhu, Ph.D. Dept. of Computer Science and mathematics, Nipissing University, 100.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.1.
An Introduction to Software Architecture
By: Md Rezaul Huda Reza 5Ps for SE Process Project Product People Problem.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 2Slide 1 Chapter 2 Computer-Based System Engineering As modified by Randy Smith.
RTS Meeting 8th July 2009 Introduction Middleware AUTOSAR Conclusion.
CPSC 875 John D. McGregor Vehicle Technologies. Modern vehicles – 10 years of effort
1 Chapter 14 Architectural Design 2 Why Architecture? The architecture is not the operational software. Rather, it is a representation that enables a.
John D. McGregor Module 3 Session 2 AADL
1 Software Design Reference: Software Engineering, by Ian Sommerville, Ch. 12 & 13, 5 th edition and Ch. 10, 6 th edition.
CPSC 875 John D. McGregor C10 – Physical architecture.
1 AADL Architectural Analysis and Design Language Jason Mowry UW-Platteville Undergraduate Software Engineering.
1 Systems Analysis and Design in a Changing World, Thursday, January 18, 2007.
© 2012 xtUML.org Bill Chown – Mentor Graphics Model Driven Engineering.
CpSc 875 John D. McGregor Class 21 Ocarina/Navigation.
Software Engineering Prof. Ing. Ivo Vondrak, CSc. Dept. of Computer Science Technical University of Ostrava
REAL-TIME SOFTWARE SYSTEMS DEVELOPMENT Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
TTCN-3 MOST Challenges Maria Teodorescu
CPSC 372 John D. McGregor Module 3 Session 1 Architecture.
John D. McGregor Class 4 – Initial decomposition
TCP/IP Protocol Architecture CSE 3213 – Fall
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 18 Slide 1 Software Reuse.
CPSC 871 John D. McGregor Module 3 Session 2 AADL.
© 2006 Pearson Addison-Wesley. All rights reserved2-1 Chapter 2 Principles of Programming & Software Engineering.
EMEA Beat Schwegler Architect Microsoft EMEA HQ Ingo Rammer Principal Consultant thinktecture
Name Of The College & Dept
John D. McGregor Architecture Evaluation
B. RAMMAMURTHY Connected Vehicle Technology 6/6/2014 cse651 1.
CPSC 875 John D. McGregor Feedback Control Loop architecture Class 6.
Reverse Engineering Dept. of I&CT, MIT, Manipal. Aspects To Be Covered Introduction to reverse engineering. Comparison between reverse and forward engineering.
A Brief Introduction to Architectural Modeling Using AADL and Collaborative, Adaptive Cruise Control John D. McGregor Roselane S. Silva.
Chapter 9 Architectural Design. Why Architecture? The architecture is not the operational software. Rather, it is a representation that enables a software.
CPSC 875 John D. McGregor C16.
John D. McGregor C10 – Error architecture
Architectural Design.
CPSC 875 John D. McGregor C16.
Smart Car through IoT 라이 아샤리 리날디
John D. McGregor Quality attributes
Standards.
Chapter 9 Architectural Design
John D. McGregor Session 6 Preparing for Architecture V & V
John D. McGregor Session 5 Error Modeling
Chapter 9 Architectural Design.
John D. McGregor Quality attributes
Software Engineering: A Practitioner’s Approach, 6/e Chapter 10 Architectural Design copyright © 1996, 2001, 2005 R.S. Pressman & Associates, Inc. For.
John D. McGregor Ocarina
Presentation transcript:

CPSC 875 John D. McGregor Reference Architectures C9

Reference architecture-1 An architecture that covers a set of products rather than a single product Supports variation across products Supports abstraction in several ways – abstract – In data port {no type} – “refines to”

Reference architecture-2 abstract cacc end cacc; abstract implementation cacc.devices subcomponents radar_sensor: abstract sensor::generic_sensor.impl; radar_handler:abstract sensor::generic_sensor_handler.impl; gps:abstract sensor::generic_sensor.impl;

connections radar_handler_conn: port radar_sensor.sensor_data_out- >radar_handler.sensor_data_in; radar_conn: port radar_handler.sensor_data_out- >vehicle_controller.sensor1_data_in; camera_handler_conn: port camera_sensor.sensor_data_out- >camera_handler.sensor_data_in; camera_conn: port camera_handler.sensor_data_out- >vehicle_controller.sensor2_data_in; gps_handler_conn: port gps.sensor_data_out->gps_handler.sensor_data_in; gps_conn: port gps_handler.sensor_data_out->vehicle_controller.sensor3_data_in;

Refined to system implementation cacc_rt.devices extends abstracts::cacc.devices subcomponents vehicle_controller: refined to process control_rt.impl {Classifier_Substitution_Rule => Type_Extension;}; interface_controller:refined to process interface_controller_rt.impl; radar_sensor: refined to device devices::radarSensor_rt.impl {Classifier_Substitution_Rule => Type_Extension;}; radar_handler:refined to system devices::radar_handler.impl ;

flows -- sensor's info to logger etef0 : end to end flow radar_sensor.sensor_source -> radar_handler_conn -> radar_handler.sensor_logger_path -> logger_radar_conn-> logger.logger_sink; etef1 : end to end flow camera_sensor.sensor_source -> camera_handler_conn -> camera_handler.sensor_logger_path- > logger_camera_conn -> logger.logger_sink; etef2 : end to end flow gps.sensor_source -> gps_handler_conn -> gps_handler.sensor_logger_path -> logger_gps_conn -> logger.logger_sink;

properties latency => 5 ms.. 10 ms applies to etef0, etef1, etef2, etef3, etef4;

Abstract sensor abstract generic_sensor features sensor_data_out: out data port; flows sensor_source : flow source sensor_data_out; properties latency => 1 ms.. 3 ms applies to sensor_source; SEI::PowerBudget=> 5.0W;

annex EMV2 {** use types error_library; error propagations sensor_data_out : out propagation {NoValue}; flows ef0 : error source sensor_data_out{NoValue}; end propagations; properties emv2::hazards => ([failure => "Novalue"; description => "No data from the sensor"; ]) applies to sensor_data_out.novalue; **};

abstract abstract implementation generic_sensor.impl end generic_sensor.impl; abstract generic_sensor_handler features sensor_data_in: in data port; sensor_data_out: out data port; logger_out: out data port data_types::file;

Property set property set Bus_Properties is Bandwidth : Data_Volume applies to (bus); Bandwidth_Range : type range of Data_Volume;

Standards Few greenfield projects CVRIA Autosar AADL

CVRIA Connected Vehicle Reference Implementation Architecture Dept of Transportation Reference vs Reference Implementation

Connected Eco-system driving Enterprise view

CVRIA-Provide Traffic Surveillance 1) Process Sensor Data (1.1.1) 2) Process and Store Traffic Data (1.1.2) 3) Generate Predictive Traffic Model (PSpec 1.1.3) 4) Display and Output Traffic Data (1.1.4) 5) Exchange Data with Other Traffic Centers (PSpec 1.1.5) 6) Collect Vehicle Traffic Probe Data (PSpec 1.1.6) 7) Collect Vehicle Environmental Data (PSpec 1.1.7) Functional processes

Physical view

Communication view

Standards Development Organizations The following organizations participate in ITS standards activities: AASHTO (American Association of State Highway and Transportation Officials) ANSI (American National Standards Institute) APTA (American Public Transportation Association) ASTM (American Society for Testing and Materials) IEEE (Institute of Electrical and Electronics Engineers) ITE (Institute of Transportation Engineers) NEMA (National Electrical Manufacturers Association) SAE (Society of Automotive Engineers)

Documentation

Autosar Structured membership

Document Lifecycle The following specifications change their life cycle status with this release. New Specifications The following specifications are added to this release: Supplementary material of general blueprints for AUTOSAR (UID 682, TR, aux) Functional Safety analysis of an exemplary system using AUTOSAR (UID 641, EXP, aux) Obsolete Specifications The following specifications are set to status “obsolete” in this release: Requirements on Debugging in AUTOSAR (UID 332, SRS, aux) Specification of Debugging in AUTOSAR (UID 315, SWS, std) These specifications are scheduled for cancellation, i.e. removal from standard with the next minor release. In case of objections against the planned cancellation of any of the specifications listed above, please submit your objections to AUTOSAR by an to Canceled The following specifications are set to status “canceled” in this release: Example for a Serialization Protocol (SOME/IP) (UID 637, TR, aux) The content of this technical report will be merged into a new specification of a future release.

Sensor/Actuator Design Pattern Problem The Sensor/Actuator Design Pattern describes how to handle sensors or actuators that are connected to an ECU in the context of an overall architecture. The Sensor/Actuator Design Pattern focuses on aspects of: Independence of application software from concrete sensors and actuators connected to a specific ECU. Reusable code between different sensors and actuators. Different code sharing cooperation models (software sharing), thus supporting different business models. Deployment of functionality to different ECUs.

Example

ECU mapping

AADL 1REFERENCES 1.1Normative References 1.2Informative References 1.3Method of Description and Syntax Notation ANNEX DOCUMENT EERROR MODEL Annex E.1Scope Annex E.2Concepts and Terminology Annex E.3Error Model Libraries Annex E.4Error Model Subclauses Annex E.5Error Types, Type Products, Type Sets, and Type Hierarchies Annex E.6A Common Set of Error Types E.6.1Service Related Errors

Systems and software engineering — Architecture description ISO/IEC/IEEE 42010

Description

ADL

Install ocarina

tina

Output from ocarina

Graphviz has dot and neato

Drawn petri net

Activate simulator

Click on Rand, then Stop, then use the forward and reverse keys

Client/server example

Walk thru execution