Parameter Dependencies for Component Reliability Specifications

•

1 gefällt mir•977 views

This document presents a solution for determining transition probabilities for component reliability specifications using Markov models. The proposed approach models components as control flow graphs containing internal actions, branches, external calls, loops, and failure probabilities. Parameter dependencies capture how failure probabilities and branch probabilities may depend on input parameters. The model is transformed into a Markov model to calculate component reliability. The approach is demonstrated on a case study of an inventory service component from a retail management system.

Technologie Business

Parameter Dependencies for Component Reliability Specifications HeikoKoziolek (ABB Corporate Research)Franz Brosch (FZI Karlsruhe, Germany)

Heiko Koziolek: Parameter Dependencies for Component Reliability Specifications 1 EU Project Q-ImPrESS Quality Impact Prediction for Evolving Service-oriented Software www.q-impress.eu

Software Reliability Heiko Koziolek: Parameter Dependencies for Component Reliability Specifications 2 [Musa1987]

Architecture-basedReliability Analysis Heiko Koziolek: Parameter Dependencies for Component Reliability Specifications 3 Markov Model ComponentArchitecture R = 0.9223 ExpectedReliability Markov Model Solution [Trivedi2001]

Problem Heiko Koziolek: Parameter Dependencies for Component Reliability Specifications 4 Howtodeterminethetransitionprobabilities?

Literature: Existing Approaches Heiko Koziolek: Parameter Dependencies for Component Reliability Specifications 5

Our Solution Heiko Koziolek: Parameter Dependencies for Component Reliability Specifications 6

Our Solution: Model Heiko Koziolek: Parameter Dependencies for Component Reliability Specifications 7 Internal Action BranchProbability Sequence Branch External Call

Our Solution: Model Heiko Koziolek: Parameter Dependencies for Component Reliability Specifications 8 FailureProbability BranchProbability ExternalCall Inputs Parameter Dependency Parameter Dependency Input Parameter Input Parameter

Our Solution: Model Heiko Koziolek: Parameter Dependencies for Component Reliability Specifications 9 Loop NumberofIterations

Our Solution: Model Heiko Koziolek: Parameter Dependencies for Component Reliability Specifications 10

Our Solution: Transformation Heiko Koziolek: Parameter Dependencies for Component Reliability Specifications 11

Our Solution: Markov Model Solution Heiko Koziolek: Parameter Dependencies for Component Reliability Specifications 12 R Q [Trivedi2001]

Case Study: Retail Management System Heiko Koziolek: Parameter Dependencies for Component Reliability Specifications 13

Case Study: Inventory Service - BookSale Heiko Koziolek: Parameter Dependencies for Component Reliability Specifications 14

Case Study: Modelling Heiko Koziolek: Parameter Dependencies for Component Reliability Specifications 15 Parameter Dependency on Loop Count ComponentArchitecture PalladioTool Control Flow Graph for a Component Service

Case Study: Analysis Heiko Koziolek: Parameter Dependencies for Component Reliability Specifications 16 PalladioTool Markov Model Solution

Case Study: ReliabilityPredictionResults Heiko Koziolek: Parameter Dependencies for Component Reliability Specifications 17

Case Study: ReliabilityPredictionResults Heiko Koziolek: Parameter Dependencies for Component Reliability Specifications 18

Assumptions & Limitations Markov Property FailureProbabilities Determiniation? Stochastically Independent Constant Expressiveness No Hardware Failures NoConcurrency NoRepair Getting Parameter Dependencies Heiko Koziolek: Parameter Dependencies for Component Reliability Specifications 19

Conclusion Parameter DependenciesforComponentReliabilitySpecifications Modellingbycomponentdeveloperandsoftwarearchitect Easy alternationofsystem-levelusageprofile Reusablereliabilityspecifications Heiko Koziolek: Parameter Dependencies for Component Reliability Specifications 20 www.q-impress.eu

Weitere ähnliche Inhalte

Ähnlich wie Parameter Dependencies for Component Reliability Specifications

Agile Entwicklung, das hat was von Leichtigkeit, und agile Entwicklung trägt tatsächlich dazu bei, bessere Ergebnisse früher zu erzielen. Es gilt aber auch: Der Prozess ist stikter, als Sie das heute leben. Scrum ist strikter gegenüber Management, und erfordert einen funktionierenden Integrations- und Testprozess. Vor allem in Embedded Systemen. Mehr zum Thema auf http://www.elektrobit.com/consulting Agil klingt innovativ, fluffig, ebenso Scrum mit seinen User Stories, dem Zusammenarbeiten. Das agilenPrinzip, Änderungen willkommen zu heißen, lässt das höhere Management in Entwicklungsorganisationen und deren Kunden in freudiger Schnappatmung erzittern. Verheißt dies doch die Möglichkeit, ohne sauer dreinblickende Projektmanager auch zwischendrin mal das Ruder rumzureißen, und das ganze auch noch mit dem Segen des Agilen Manifests und mit einem Framework namens Scrum. Wessen Organisation agil entwickelt, der freut sich, innovative Methoden zu verwenden, mit schlanken Prozessen und kaum Overhead, und vor allem gleich damit starten zu können. Echt jetzt? Wenn Ihre Organisation mit Scrum wirklich erfolgreich sein will, dann ist das kein Zuckerschlecken. Der Prozess ist mit hoher Wahrscheinlichkeit deutlich stikter, als Sie das heute leben. Scrum ist strikter gegenüber dem Management außerhalb des Teams, und Scrum ist strikter und zu Beginn der Einführung anstrengender als Ihr heutiger Integrations- und Testprozess. Vor allem in Embedded Systemen. Der erste agile Wert sagt „Individuals and interactions over processes and tools.“ Und um eben im täglichen Arbeiten den Menschen und Interaktionen eine höhere Bedeutung einräumen zu können, ist es so wichtig, dass Prozess und Tools vorhanden sind, funktionieren und ganz natürlich benutzt werden. Scrum, Kanban und andere agile Methoden erlauben den Menschen in Organisationen, streßfreier hervorragende Qualität zu liefern, erlauben internen und externen Kunden, früher werthaltige Lösungen zu bekommen, und machen aufs große Ganze gesehen der eigenen Organisation bessere Planung. In diesem Vortrag sehen Sie, was Sie zum Agilen Entwickeln mit Scrum lieber nicht sehen wollten, und wie Sie endlich einen Nutzen fürs Projekt, fürs Unternehmen, für den Kunden und für die Mitarbeiter aus Scrum ziehen können.

Scrum für Embedded-Software: Gut – aber aus anderen Gründen, als Ihr Manager...

Joachim Schlosser

White paper mbre_en

VisioneerUG

Ch5 software imprementation1.0

Kittitouch Suteeca

2009 scrum & architecture

Andreas Wintersteiger

ETCA_4

PMI2011

1530 sulimov

Rising Media, Inc.

Defining and Aligning Requirements using System Architect and DOORS

Paul W. Johnson

RPWORLD On-demand Manufacturing.pdf

zhanjim40

Reliability Engineering 101 training is a 2-day basic reliability engineering training course for electrical, mechanical, software, maintenance, reliability and quality assurance engineers, project managers and technicians covering the fundamentals of reliability. Learning Objectives: Describe basic concepts of reliability engineering List the motivations for reliability and reliability engineering List the various reliability benefits applied to process, design, products and systems Explain different reliability terms and concepts such as MTBF, MTTR and MTTF Discuss differences and similarities between failure rate, reliability, availability and unavailability Discuss reliability of a repairable vs.a non-repairable system Discuss different reliability predictions models including MIL-217, Telcordia, Explain the role of design tools for reliability predictions Describe FMEA, FMECA, Process FMEA, Design FMEA, FTA, RDB, Markov, and Event Tree Analysis (ETA) Course Content: What is Reliability? What is Reliability Engineering? Reliability Management Reliability Modeling and Predictions Reliability Engineering 101 course is intended for anyone interested in understanding what reliability and reliability engineering are and how it will transform their products and systems development to the desired state. Learn more about reliability engineering 101. Visit Tonex.com link below Reliability Engineering 101 https://www.tonex.com/training-courses/reliability-engineering-101/

Reliability Engineering 101 : Tonex Training

Bryan Len

Condition monitoring, production efficiency, traceability

ifm electronic gmbh

Design for reliability (DFR) is an industry-wide practice and a philosophy of considering reliability in an early stage of product design and development, to achieve a highly-reliable product while with sustainable cost. Physical of Failure (PoF) is recognized as a key approach of implementing DFR in a product design and development process. The author will present a case study to illustrate predicting and identifying product failure early in the design phase with the help of a quantitative PoF model based analysis tool.

DFR a case study using a physics of failure

ASQ Reliability Division

Running head: MODEL-BASED SYSTEMS ENGINEERING IMPLEMENTATION 1 Research Project: Model-Based Systems Engineering Implementation (Name and date withheld) MODEL-BASED SYSTEMS ENGINEERING IMPLEMENTATION 2 Model-Based Systems Engineering (MBSE) Implementation Section 1: Requirements Analysis Section 1 tasks for the MBSE project will identify issues and requirements for implementing an MBSE system for our Engineering and Systems Integration work. Problem Definition Our Engineering department focuses on a niche market of systems engineering, design, integration, and ongoing maintenance and support of emergency communication and power systems, predominantly housed in High-Altitude Electromagnetic Pulse (HEMP) protected mobile environments. The complexity of the integrated voice, data, network, and audio/video systems we work with, the specialized nature of the work, and the demanding project timelines have put a strain on our resources and existing processes. We need to leverage common requirements and design elements across projects and customers while remaining adaptive to unique and changing customer needs. With people spread across multiple projects, it is harder to capture changes on one system that should be implemented on others – especially since requirements and design files are all in separate Word, Excel, Visio and other documents. We would also like to expand our business to new customers with complex Systems-of-Systems (SoS) environments that may require protections from HEMP events. To do that, we need to streamline our processes and reduce redundant work to allow people to reasonably take on additional projects and make new hires productive on project work more quickly – while maintaining critical quality factors. Issues requiring solution. The following list describes the primary issues requiring the development of an MBSE system for Engineering. 1. Business growth is placing a strain on senior employees with specialized skills and knowledge. MODEL-BASED SYSTEMS ENGINEERING IMPLEMENTATION 3 2. System information is contained in a large, diverse set of files (Excel files, Word documents, Visio diagrams, and CAD files) with no easy way to share technical information. 3. We can’t easily reuse or modify applicable requirements and design elements between projects. This increases cost and effort of new work. 4. It 's hard to perform change management and assess impacts on a short timeline across the systems’ lifecycle, again increasing workloads and quality risks. 5. We’re not able to quickly evaluate new customer requirements and designs against existing systems efficiently, increasing the effort and response time on customer proposals. 6. There is an increasing demand from customers to see architectural views and interconnecting systems that help them understand the proposed designs. 7. Consistently high workloads cause bottlenecks that slow ...

Running head MODEL-BASED SYSTEMS ENGINEERING IMPLEMENTATION 1.docx

cowinhelen

iLumTech - Electronic design services

iLumTech

Reliability growth planning (RGP) is emerging as a promising technique to address the reliability challenges arising from the distributed manufacturing environment. Unlike RGT (reliability growth testing), RGP drives the reliability growth of new products by spanning the product’s lifecycle from design, prototyping, manufacturing, to field use. It is a lifetime commitment to the product reliability via systematic failure analysis, rigorous corrective actions, and cost-effective financial investment. RGP has shown to be very effective, particularly in new product introductions under the fast time-to-market requirement. The RGP process will be introduced based on the three-phase product lifecycle: 1) design for reliability during early product development; 2) accelerated lifetime testing and corrective actions in pilot line stage; and 3) continuous reliability improvement following the volume shipment. Trade-offs among reliability investment, warranty cost reduction, and customer satisfactions will be investigated from the perspective of the manufacturer and the customer. Reliability growth tools such as Crow/AMSAA, Pareto graphs, failure mode run chart, FIT (failure-in-time), and FMECA will be reviewed and their roles in the GRP process will be discussed and demonstrated. Case studies drawn from electronics equipment industry will be used to demonstrate the RGP applications and justify its benefits as well. In parallel with the RGP, efforts have been devoted to developing optimal preventative maintenance programs, either time-based or usage-based strategies. Recently, CBM (condition based maintenance) is showing a great potential to achieve just-in-time maintenance or zero-downtime equipment. RGP and maintenance strategies share a common objective, i.e. achieving high system reliability and availability. In this presentation, optimal maintenance policies will be devised in the context of system reliability growth.

Reliability Growth Planning: Its Concept, Applications, and Challenges

ASQ Reliability Division

Infrastructure

Yujuan Jiang

Converting to the latest COBOL Compiler made simple with the right tools

DevOps for Enterprise Systems

Abstract The external and internal mirrors used particularly in high mass recreational and commercial vehicles are prone to vibrations. Effect of undesired vibrations in the mirror assembly like blurring of image, breaking of the mirror glass, breaking of plastic mounting bracket due to resonance is a major challenge and requires vibration analysis based studies during the development stage of the mirror assembly. The purpose of this study was to carry out vibration analysis on a basic pre-existing mirror assembly from an OEM (original equipment manufacturer) and further develop this assembly to increase its first fundamental frequency above the target specified by the OEM. Finite element model for the automobile rear view mirror was created to predict mirror vibration response based on modal analysis study. The design changes in various parts of mirror assembly were done in solid works and the Hypermesh 9.0 was used to prepare the FEA model. The materials used in this FEA model were initially provided by the mirror manufacturer and also some modification was done based on the study. Hypermesh Optistruct solver was used to build the complete FEA ORVM model. Vibration modes were predicted for the mirror assembly with a special focus on the mirror mounting bracket as it’s the only part through which the vibrations transfers to mirror assembly in actual vehicle. The natural frequency of the first mirror FEA model was correlated with the first test results and then further iterations were done using this FEA model to predict the changes required in material and geometry to achieve the target frequency value.

The vibration analysis of automobile outer rear view mirror with its developm...

eSAT Journals

3 martin heininger - software unit testing autonomous cars verified by aero...

Ievgenii Katsan

Assignment Instructions The case study is a project management scenario, which needs to be engaged as a project manager. The case information is not complete so where necessary students will have to argue the advantages and disadvantages of assumptions made. Files are to be made in MS Project 2010 and MS Word. Assumptions You are free to make any assumptions necessary to complete the assignment. However, each assumption must be justified and stated clearly in your assessment Word document. Marks will be deducted for any unreasonable assumption or for stating an assumption and then ignoring it in your assignment. For assumptions made, you are expected to find relevant information in the academic literature to justify your answer and provide appropriate references (2 minimum). For this assignment completion you need four separate files: 1. The Word document with the assumptions and solutions to the questions for Part A and Part B. 2. The Microsoft Project 2010 files created for Part A and Part B. Please ensure that the Microsoft Project files are named according to the instructions in the assignment specification (AZMotionPartA1.mpp, AZMotionPartA2.mpp and AZMotionPartB.mpp). Product Development Case Description Background AZMotion is a medium sized company that develops and manufactures industrial monitoring equipment. You are an employee of AZMotion and work as project manager in the product development department. The people involved in this case are: • You are Mr. Project, the project manager. • Mr. Product is the Director of Product Development. • Ms. Marketing is the Director of Marketing and Portfolio Management. • Ms. Resource is the Human Resource Manager. • Functional line managers in the research and development department. • Engineers and members of your project team. You have been leading a small team of experienced engineers conducting a technical feasibility study to investigate if it is possible to modify one of the company’s standard products to create a product variant to satisfy the needs of the mining industry. The M1 Milestone Concept Review will be held on Friday 5th September 2014. The project management milestone concept review checklist is provided below. The Project Management Milestone Checklist for M1 1. Are the marketing requirements agreed? 2. Are project targets agreed (e.g. schedule, features and quality)? 3. Has a feasibility study been successfully completed? 4. Is the product concept selected and well understood? 5. Are user product mock‐ups circulated and reviewed with marketing? 6. Are the product and production technologies selected? 7. Have key components and suppliers been identified? 8. Has the supply chain impact of a new product been reviewed? 9. Is the project organization agreed? 10. Is the project team established and operational? 11. Is any projec ...

Assignment Instructions The case study is a project manag.docx

ssuser562afc1

Build for the future

Mostafa Elfeky

Ähnlich wie Parameter Dependencies for Component Reliability Specifications (20)

Scrum für Embedded-Software: Gut – aber aus anderen Gründen, als Ihr Manager...

White paper mbre_en

Ch5 software imprementation1.0

2009 scrum & architecture

ETCA_4

1530 sulimov

Defining and Aligning Requirements using System Architect and DOORS

RPWORLD On-demand Manufacturing.pdf

Reliability Engineering 101 : Tonex Training

Condition monitoring, production efficiency, traceability

DFR a case study using a physics of failure

Running head MODEL-BASED SYSTEMS ENGINEERING IMPLEMENTATION 1.docx

iLumTech - Electronic design services

Reliability Growth Planning: Its Concept, Applications, and Challenges

Infrastructure

Converting to the latest COBOL Compiler made simple with the right tools

The vibration analysis of automobile outer rear view mirror with its developm...

3 martin heininger - software unit testing autonomous cars verified by aero...

Assignment Instructions The case study is a project manag.docx

Build for the future

Mehr von Heiko Koziolek

The OPC UA communication architecture is currently becoming an integral part of industrial automation systems, which control complex production processes, such as electric power generation or paper production. With a recently released extension for pub/sub communication, OPC UA can now also support fast cyclic control applications, but the bottlenecks of OPC UA implementations and their scalability on resource-constrained industrial devices are not yet well understood. Former OPC UA performance evaluations mainly concerned client/server round-trip times or focused on jitter, but did not explore resource bottlenecks or create predictive performance models. We have carried out extensive performance measurements with OPC UA client/server and pub/sub communication and created a CPU utilization prediction model based on linear regression that can be used to size hardware environments. We found that the server CPU is the main bottleneck for OPC UA pub/sub communication, but allows a throughput of up to 40,000 signals per second on a Raspberry Pi Zero. We also found that the client/server session management overhead can severely impact performance, if more than 20 clients access a single server.

Bottleneck Identification and Performance Modeling of OPC UA Communication Mo...

Heiko Koziolek

The concepts of decision forces and the decision forces viewpoint were proposed to help software architects to make architectural decisions more transparent and the documentation of their rationales more explicit. However, practical experience reports and guidelines on how to use the viewpoint in typical industrial project setups are not available. Existing works mainly focus on basic tool support for the documentation of the viewpoint or show how forces can be used as part of focused architecture review sessions. With this paper, we share experiences and lessons learned from applying the decision forces viewpoint in a distributed industrial project setup, which involves consultants supporting architects during the re-design process of an existing large software system. Alongside our findings, we describe new forces that can serve as template for similar projects, discuss challenges applying them in a distributed consultancy project, and share ideas for potential extensions.

Architectural Decision Forces at Work: Experiences in an Industrial Consultan...

Heiko Koziolek

Industrial control systems are complex, software-intensive systems that manage mission-critical production processes. Commissioning such systems requires installing, configuring, and integrating thousands of sensors, actuators, and controllers and is still a largely manual and costly process. Therefore, practitioners and researchers have been working on ``plug and produce'' approaches that automate commissioning for more than 15 years, but have often focused on network discovery and proprietary technologies. We introduce the vendor-neutral OpenPnP reference architecture, which can largely automate the configuration and integration tasks for commissioning. Using an example implementation, we demonstrate that OpenPnP can reduce the configuration and integration effort up to 90 percent and scales up to tens of thousands of communicated signals per second for large Industrial Internet-of-Things (IIoT) systems. OpenPnP can serve as a template for practitioners implementing IIoT applications throughout the automation industry and streamline commissioning processes in many thousands of control system installations.

OpenPnP: a Plug-and-Produce Architecture for the Industrial Internet of Things

Heiko Koziolek

This talk presentst the tool-driven technology transfer process ABB Corporate Research applies in selected software engineering University collaborations. As an example, we have created an add-in to a popular UML tool and developed the tooling in close interaction with the target users. Centering the technology transfer around tool implementations brings many benefits such as the need to make conceptual contributions applicable and the ability to quickly benefit from the new concepts. A challenge to this form of technology transfer is the long-term commitment to the maintenance of the tooling, which we try to address by creating an open developer community. Tool-driven technology transfer projects have proven to be valuable a instrument of bringing advanced software engineering technologies into our organization.

Tool-Driven Technology Transfer in Software Engineering

Heiko Koziolek

Distributed control systems are currently evolving towards Industrial Internet-of-Things (IIoT) systems. Still, they still suffer from complex commissioning processes that incur high costs. Researchers have proposed several so-called ''Plug and Produce'' (PnP) approaches, where commissioning shall be largely automated, but they have suffered from semantic ambiguities and usually rely on proprietary information models. This talk introduces a novel reference architecture for PnP in IIoT systems, which is based on OPC UA and PLCopen standards and can reduce industrial device commissioning times across vendor products to a few seconds. Our proof-of-concept implementation can handle more than 500 signals per millisecond during runtime, sufficient for most application scenarios.

Self-commissioning Industrial IoT Systems

Heiko Koziolek

Distributed control systems for manufacturing are currently evolving towards Industrial Internet-of-Things (IIoT) systems. Sensors and actuators get equipped with internet connectivity, which allows them to interface with cloud platforms. This potentially enables a number of application cases. However, industrial "things" may be much more complex and more resource-constrained than typical consumer space "things". This talk provides an overview of Industrial IoT application cases and sketches various challenges for researchers and practitioners using the example of turning a level sensor for industrial tanks into an IoT device.

IoT challenges for Smart Manufacturing

Heiko Koziolek

Distributed control systems are currently evolving towards Industrial Internet-of-Things (IIoT) systems. Still, they still suffer from complex commissioning processes that incur high costs. Researchers have proposed several so-called ''Plug and Produce'' (PnP) approaches, where commissioning shall be largely automated, but they have suffered from semantic ambiguities and usually rely on proprietary information models. We propose a novel reference architecture for PnP in IIoT systems, which is based on OPC UA and PLCopen standards and can reduce industrial device commissioning times across vendor products to a few seconds. Our proof-of-concept implementation can handle more than 500 signals per millisecond during runtime, sufficient for most application scenarios.

Software Architecture in Process Automation: UML & the "Smart Factory"

Heiko Koziolek

Engineering and commissioning field devices and production modules in typical manufacturing settings is today still a largely manual and often error-prone process. Most proposed Plug&Produce approaches rely on proprietary technologies, device descriptions, and device functionalities and thus cannot incorporate devices from different vendors. In this contribution, we propose a minimal, but expressive AAS structure that is fully based on industry standards and Namur recommendations. We show how this AAS structure can be mapped to different communication technologies, such as OPC UA and MQTT. As a proof-of-concept, we have implemented a prototype using the proposed AAS structure to realize a restricted device-level PnP scenario. Due to the use of standards, our results can be easily reproduced by researchers and practitioners, so that a broad applicability of our concepts is possible.

Plug-and-Produce based on Standardized Industrie 4.0 Asset Admin Shells

Heiko Koziolek

Despite significant scientific research, systematic performance engineering techniques are still hardly used in industry, as many practitioners rely on ad-hoc performance firefighting. It is still not well understood where more sophisticated performance modeling approaches are appropriate and the maturity of the existing tools and processes can be improved. While there have been several industrial case studies on performance modeling in the last few years, more experience is needed to better understand the constraints in practice and to optimize existing tool-chains. I gave a talk summarizing six years of performance modeling at ABB. In three projects, different approaches to performance modeling were taken, and experiences on the capabilities and limitations of existing tools were gathered. The talk reports on several lessons learned from these projects, for example the need for more efficient performance modeling and the integration of measurement and modeling tools.

6 Years of Performance Modeling at ABB

Heiko Koziolek

Future industrial automation systems will execute a number of control and monitoring functions in central data centers. The cloud computing paradigm will reduce IT costs and enable small companies to flexibly automate production processes. Centralized control and monitoring across companies and domains will facilitate a novel smart ecosystem for industrial automation connecting both embedded devices and information systems. To realize this vision, a number of technical, economical, and social challenges need to be solved. This talk focuses on software architecture challenges for cloud-connected automation systems. It points out the architectural impact of critical non-functional properties, such as latency, security, and multi-tenancy.

Towards the Automation Cloud: Architectural Challenges for a Novel Smart Ecos...

Heiko Koziolek

Managing the cost-effective evolution of industrial software systems is a challenging task because of their complexity and long lifetimes. Limited pro-active evolution planning and software architecture erosion often lead to huge maintenance costs in such systems. However, formerly researched approaches for evolution scenario analysis and architecture enforcement are only reluctantly applied by practitioners due to their perceived overhead and high costs. We have applied several recent sustainability evaluation and improvement approaches in a case study to the software architecture of a large industrial software system currently under development at ABB. We combined our selection of approaches in a lightweight method called MORPHOSIS, for which this paper presents experiences and lessons learned. We found that reasonable sustainability evaluation and improvement is possible already with limited efforts.

MORPHOSIS: A Case Study on Lightweight Architecture Sustainability Analysis

Heiko Koziolek

The SPOSAD Architectural Style for Multi-tenant Software Applications

Heiko Koziolek

2011 05-27-icse

Heiko Koziolek

A Large-Scale Industrial Case Study on Architecture-based Software Reliabilit...

Heiko Koziolek

Multi-tenant software applications serve different organizations from a single instance and help to save development, maintenance, and administration costs. The architectural concepts of these applications and their relation to emerging platform-as-a-service (PaaS) environments are still not well understood, so that it is hard for many developers to design and implement such an application. Existing attempts at a structured documentation of the underlying concepts are either technology-specific or restricted to certain details. We propose documenting the concepts as a new architectural style. This paper initially describes the architectural properties, elements, views, and constraints of this style. We illustrate how the architectural elements are implemented in current PaaS environments, such as Force.com, Windows Azure, and Google App Engine.

Towards an Architectural Style for Multi-tenant Software Applications

Heiko Koziolek

PerOpteryx

Heiko Koziolek

Evolving Industrial Software Architectures into a Software Product Line: A Ca...

Heiko Koziolek

Mehr von Heiko Koziolek (17)

Bottleneck Identification and Performance Modeling of OPC UA Communication Mo...

Architectural Decision Forces at Work: Experiences in an Industrial Consultan...

OpenPnP: a Plug-and-Produce Architecture for the Industrial Internet of Things

Tool-Driven Technology Transfer in Software Engineering

Self-commissioning Industrial IoT Systems

IoT challenges for Smart Manufacturing

Software Architecture in Process Automation: UML & the "Smart Factory"

Plug-and-Produce based on Standardized Industrie 4.0 Asset Admin Shells

6 Years of Performance Modeling at ABB

Towards the Automation Cloud: Architectural Challenges for a Novel Smart Ecos...

MORPHOSIS: A Case Study on Lightweight Architecture Sustainability Analysis

The SPOSAD Architectural Style for Multi-tenant Software Applications

2011 05-27-icse

A Large-Scale Industrial Case Study on Architecture-based Software Reliabilit...

Towards an Architectural Style for Multi-tenant Software Applications

PerOpteryx

Evolving Industrial Software Architectures into a Software Product Line: A Ca...

Kürzlich hochgeladen

Manulife - Insurer Innovation Award 2024

The Digital Insurer

Data Cloud, More than a CDP by Matt Robison

Anna Loughnan Colquhoun

Building Digital Trust in a Digital Economy Veronica Tan, Director - Cyber Security Agency of Singapore Apidays Singapore 2024: Connecting Customers, Business and Technology (April 17 & 18, 2024) ------ Check out our conferences at https://www.apidays.global/ Do you want to sponsor or talk at one of our conferences? https://apidays.typeform.com/to/ILJeAaV8 Learn more on APIscene, the global media made by the community for the community: https://www.apiscene.io Explore the API ecosystem with the API Landscape: https://apilandscape.apiscene.io/

Apidays Singapore 2024 - Building Digital Trust in a Digital Economy by Veron...

apidays

In this session, we will delve into strategic approaches for optimizing knowledge management within Microsoft 365, amidst the evolving landscape of Copilot. From leveraging automatic metadata classification and permission governance with SharePoint Premium, to unlocking Viva Engage for the cultivation of knowledge and communities, you will gain actionable insights to bolster your organization's knowledge-sharing initiatives. In this session, we will also explore how to facilitate solutions to enable your employees to find answers and expertise within Microsoft 365. You will leave equipped with practical techniques and a deeper understanding of how there is more to effective knowledge management than just enabling Copilot, but building actual solutions to prepare the knowledge that Copilot and your employees can use.

Strategies for Unlocking Knowledge Management in Microsoft 365 in the Copilot...

Drew Madelung

AWS Community Day CPH - Three problems of Terraform

Andrey Devyatkin

Partners Life - Insurer Innovation Award 2024

The Digital Insurer

ProductAnonymous-April2024-WinProductDiscovery-MelissaKlemke

Product Anonymous

Polkadot JAM Slides - Token2049 - By Dr. Gavin Wood

Juan lago vázquez

2024: Domino Containers - The Next Step. News from the Domino Container commu...

Martijn de Jong

Artificial Intelligence Chap.5 : Uncertainty

Khushali Kathiriya

The presentation explores the development and application of artificial intelligence (AI) from its inception to its current status in the modern world. The term "artificial intelligence" was first coined by John McCarthy in 1956 to describe efforts to develop computer programs capable of performing tasks that typically require human intelligence. This concept was first introduced at a conference held at Dartmouth College, where programs demonstrated capabilities such as playing chess, proving theorems, and interpreting texts. In the early stages, Alan Turing contributed to the field by defining intelligence as the ability of a being to respond to certain questions intelligently, proposing what is now known as the Turing Test to evaluate the presence of intelligent behavior in machines. As the decades progressed, AI evolved significantly. The 1980s focused on machine learning, teaching computers to learn from data, leading to the development of models that could improve their performance based on their experiences. The 1990s and 2000s saw further advances in algorithms and computational power, which allowed for more sophisticated data analysis techniques, including data mining. By the 2010s, the proliferation of big data and the refinement of deep learning techniques enabled AI to become mainstream. Notable milestones included the success of Google's AlphaGo and advancements in autonomous vehicles by companies like Tesla and Waymo. A major theme of the presentation is the application of generative AI, which has been used for tasks such as natural language text generation, translation, and question answering. Generative AI uses large datasets to train models that can then produce new, coherent pieces of text or other media. The presentation also discusses the ethical implications and the need for regulation in AI, highlighting issues such as privacy, bias, and the potential for misuse. These concerns have prompted calls for comprehensive regulations to ensure the safe and equitable use of AI technologies. Artificial intelligence has also played a significant role in healthcare, particularly highlighted during the COVID-19 pandemic, where it was used in drug discovery, vaccine development, and analyzing the spread of the virus. The capabilities of AI in healthcare are vast, ranging from medical diagnostics to personalized medicine, demonstrating the technology's potential to revolutionize fields beyond just technical or consumer applications. In conclusion, AI continues to be a rapidly evolving field with significant implications for various aspects of society. The development from theoretical concepts to real-world applications illustrates both the potential benefits and the challenges that come with integrating advanced technologies into everyday life. The ongoing discussion about AI ethics and regulation underscores the importance of managing these technologies responsibly to maximize their their benefits while minimizing potential harms.

Artificial Intelligence: Facts and Myths

Joaquim Jorge

The Good, the Bad and the Governed - Why is governance a dirty word? David O'Neill, Chief Operating Officer - APIContext Apidays New York 2024: The API Economy in the AI Era (April 30 & May 1, 2024) ------ Check out our conferences at https://www.apidays.global/ Do you want to sponsor or talk at one of our conferences? https://apidays.typeform.com/to/ILJeAaV8 Learn more on APIscene, the global media made by the community for the community: https://www.apiscene.io Explore the API ecosystem with the API Landscape: https://apilandscape.apiscene.io/

Apidays New York 2024 - The Good, the Bad and the Governed by David O'Neill, ...

apidays

This presentations targets students or working professionals. You may know Google for search, YouTube, Android, Chrome, and Gmail, but did you know Google has many developer tools, platforms & APIs? This comprehensive yet still high-level overview outlines the most impactful tools for where to run your code, store & analyze your data. It will also inspire you as to what's possible. This talk is 50 minutes in length.

Powerful Google developer tools for immediate impact! (2023-24 C)

wesley chun

As privacy and data protection regulations evolve rapidly, organizations operating in multiple jurisdictions face mounting challenges to ensure compliance and safeguard customer data. With state-specific privacy laws coming up in multiple states this year, it is essential to understand what their unique data protection regulations will require clearly. How will data privacy evolve in the US in 2024? How to stay compliant? Our panellists will guide you through the intricacies of these states' specific data privacy laws, clarifying complex legal frameworks and compliance requirements. This webinar will review: - The essential aspects of each state's privacy landscape and the latest updates - Common compliance challenges faced by organizations operating in multiple states and best practices to achieve regulatory adherence - Valuable insights into potential changes to existing regulations and prepare your organization for the evolving landscape

TrustArc Webinar - Stay Ahead of US State Data Privacy Law Developments

TrustArc

GenAI Risks & Security Meetup 01052024.pdf

lior mazor

Workshop - Best of Both Worlds_ Combine KG and Vector search for enhanced R...

Neo4j

Repurposing LNG terminals for Hydrogen Ammonia: Feasibility and Cost Saving

Edi Saputra

💉💊+971581248768>> SAFE AND ORIGINAL ABORTION PILLS FOR SALE IN DUBAI AND ABUDHABI}}+971581248768 +971581248768 Mtp-Kit (500MG) Prices » Dubai [(+971581248768**)] Abortion Pills For Sale In Dubai, UAE, Mifepristone and Misoprostol Tablets Available In Dubai, UAE CONTACT DR.Maya Whatsapp +971581248768 We Have Abortion Pills / Cytotec Tablets /Mifegest Kit Available in Dubai, Sharjah, Abudhabi, Ajman, Alain, Fujairah, Ras Al Khaimah, Umm Al Quwain, UAE, Buy cytotec in Dubai +971581248768''''Abortion Pills near me DUBAI | ABU DHABI|UAE. Price of Misoprostol, Cytotec” +971581248768' Dr.DEEM ''BUY ABORTION PILLS MIFEGEST KIT, MISOPROTONE, CYTOTEC PILLS IN DUBAI, ABU DHABI,UAE'' Contact me now via What's App…… abortion Pills Cytotec also available Oman Qatar Doha Saudi Arabia Bahrain Above all, Cytotec Abortion Pills are Available In Dubai / UAE, you will be very happy to do abortion in Dubai we are providing cytotec 200mg abortion pill in Dubai, UAE. Medication abortion offers an alternative to Surgical Abortion for women in the early weeks of pregnancy. We only offer abortion pills from 1 week-6 Months. We then advise you to use surgery if its beyond 6 months. Our Abu Dhabi, Ajman, Al Ain, Dubai, Fujairah, Ras Al Khaimah (RAK), Sharjah, Umm Al Quwain (UAQ) United Arab Emirates Abortion Clinic provides the safest and most advanced techniques for providing non-surgical, medical and surgical abortion methods for early through late second trimester, including the Abortion By Pill Procedure (RU 486, Mifeprex, Mifepristone, early options French Abortion Pill), Tamoxifen, Methotrexate and Cytotec (Misoprostol). The Abu Dhabi, United Arab Emirates Abortion Clinic performs Same Day Abortion Procedure using medications that are taken on the first day of the office visit and will cause the abortion to occur generally within 4 to 6 hours (as early as 30 minutes) for patients who are 3 to 12 weeks pregnant. When Mifepristone and Misoprostol are used, 50% of patients complete in 4 to 6 hours; 75% to 80% in 12 hours; and 90% in 24 hours. We use a regimen that allows for completion without the need for surgery 99% of the time. All advanced second trimester and late term pregnancies at our Tampa clinic (17 to 24 weeks or greater) can be completed within 24 hours or less 99% of the time without the need surgery. The procedure is completed with minimal to no complications. Our Women's Health Center located in Abu Dhabi, United Arab Emirates, uses the latest medications for medical abortions (RU-486, Mifeprex, Mifegyne, Mifepristone, early options French abortion pill), Methotrexate and Cytotec (Misoprostol). The safety standards of our Abu Dhabi, United Arab Emirates Abortion Doctors remain unparalleled. They consistently maintain the lowest complication rates throughout the nation. Our Physicians and staff are always available to answer questions and care for women in one of the most difficult times in their lives. The decision to have an abortion at the Abortion Cl

+971581248768>> SAFE AND ORIGINAL ABORTION PILLS FOR SALE IN DUBAI AND ABUDHA...

?#DUbAI#??##{{(☎️+971_581248768%)**%*]'#abortion pills for sale in dubai@

Strategies for Landing an Oracle DBA Job as a Fresher

Remote DBA Services

Real Time Object Detection Using Open CV

Khem

Kürzlich hochgeladen (20)

Manulife - Insurer Innovation Award 2024

Data Cloud, More than a CDP by Matt Robison

Apidays Singapore 2024 - Building Digital Trust in a Digital Economy by Veron...

Strategies for Unlocking Knowledge Management in Microsoft 365 in the Copilot...

AWS Community Day CPH - Three problems of Terraform

Partners Life - Insurer Innovation Award 2024

ProductAnonymous-April2024-WinProductDiscovery-MelissaKlemke

Polkadot JAM Slides - Token2049 - By Dr. Gavin Wood

2024: Domino Containers - The Next Step. News from the Domino Container commu...

Artificial Intelligence Chap.5 : Uncertainty

Artificial Intelligence: Facts and Myths

Apidays New York 2024 - The Good, the Bad and the Governed by David O'Neill, ...

Powerful Google developer tools for immediate impact! (2023-24 C)

TrustArc Webinar - Stay Ahead of US State Data Privacy Law Developments

GenAI Risks & Security Meetup 01052024.pdf

Workshop - Best of Both Worlds_ Combine KG and Vector search for enhanced R...

Repurposing LNG terminals for Hydrogen Ammonia: Feasibility and Cost Saving

+971581248768>> SAFE AND ORIGINAL ABORTION PILLS FOR SALE IN DUBAI AND ABUDHA...

Strategies for Landing an Oracle DBA Job as a Fresher

Real Time Object Detection Using Open CV

Parameter Dependencies for Component Reliability Specifications

1. Parameter Dependencies for Component Reliability Specifications HeikoKoziolek (ABB Corporate Research)Franz Brosch (FZI Karlsruhe, Germany)

2. Heiko Koziolek: Parameter Dependencies for Component Reliability Specifications 1 EU Project Q-ImPrESS Quality Impact Prediction for Evolving Service-oriented Software www.q-impress.eu

3. Software Reliability Heiko Koziolek: Parameter Dependencies for Component Reliability Specifications 2 [Musa1987]

4. Architecture-basedReliability Analysis Heiko Koziolek: Parameter Dependencies for Component Reliability Specifications 3 Markov Model ComponentArchitecture R = 0.9223 ExpectedReliability Markov Model Solution [Trivedi2001]

5. Problem Heiko Koziolek: Parameter Dependencies for Component Reliability Specifications 4 Howtodeterminethetransitionprobabilities?

6. Literature: Existing Approaches Heiko Koziolek: Parameter Dependencies for Component Reliability Specifications 5

7. Our Solution Heiko Koziolek: Parameter Dependencies for Component Reliability Specifications 6

8. Our Solution: Model Heiko Koziolek: Parameter Dependencies for Component Reliability Specifications 7 Internal Action BranchProbability Sequence Branch External Call

9. Our Solution: Model Heiko Koziolek: Parameter Dependencies for Component Reliability Specifications 8 FailureProbability BranchProbability ExternalCall Inputs Parameter Dependency Parameter Dependency Input Parameter Input Parameter

10. Our Solution: Model Heiko Koziolek: Parameter Dependencies for Component Reliability Specifications 9 Loop NumberofIterations

11. Our Solution: Model Heiko Koziolek: Parameter Dependencies for Component Reliability Specifications 10

12. Our Solution: Transformation Heiko Koziolek: Parameter Dependencies for Component Reliability Specifications 11

13. Our Solution: Markov Model Solution Heiko Koziolek: Parameter Dependencies for Component Reliability Specifications 12 R Q [Trivedi2001]

14. Case Study: Retail Management System Heiko Koziolek: Parameter Dependencies for Component Reliability Specifications 13

15. Case Study: Inventory Service - BookSale Heiko Koziolek: Parameter Dependencies for Component Reliability Specifications 14

16. Case Study: Modelling Heiko Koziolek: Parameter Dependencies for Component Reliability Specifications 15 Parameter Dependency on Loop Count ComponentArchitecture PalladioTool Control Flow Graph for a Component Service

17. Case Study: Analysis Heiko Koziolek: Parameter Dependencies for Component Reliability Specifications 16 PalladioTool Markov Model Solution

18. Case Study: ReliabilityPredictionResults Heiko Koziolek: Parameter Dependencies for Component Reliability Specifications 17

19. Case Study: ReliabilityPredictionResults Heiko Koziolek: Parameter Dependencies for Component Reliability Specifications 18

20. Assumptions & Limitations Markov Property FailureProbabilities Determiniation? Stochastically Independent Constant Expressiveness No Hardware Failures NoConcurrency NoRepair Getting Parameter Dependencies Heiko Koziolek: Parameter Dependencies for Component Reliability Specifications 19

21. Conclusion Parameter DependenciesforComponentReliabilitySpecifications Modellingbycomponentdeveloperandsoftwarearchitect Easy alternationofsystem-levelusageprofile Reusablereliabilityspecifications Heiko Koziolek: Parameter Dependencies for Component Reliability Specifications 20 www.q-impress.eu

Hinweis der Redaktion

Quality in the sense ofperformance, maintainability, reliability in this talk: focus on reliability
Differentlifecyclestages: design, testingTesting: SRGM, curve-fitting on reportedfailures, extrapolation, morethan 40 modelsknownDesign: Goal: determiningsoftwarereliabilitywhenpluggingtogethercomponents
About 20 approachesknownwhichfollowthiscycleGoal: Validateuserrequirements, improvearchitecture design, selectfittingcomponentsTheperceivedreliabilitydepends on howthecomponentsareused: iftheunreliablefunctionsarecalledonlyseldomly, theoverallreliabilitymight still behighFailureprobabilitiesmightbedetermined via testing individual componentsbythedevelopersAfter computingtheexpectedreliability- reliabilitycanbecomputedforcertaincomponents- find componentsmostlycontributingtooverallreliability- introduceredundancy
TransitionprobabiltiesbetweenthecomponentarisefromtheusageprofileofthesystemDepending on someuseractions, thecomponentmightpropagatecallsdirectedtothemitis vital tohaveaccuratetransitionprobabilitiesotherwisethepredictionbecomeinaccuratetheproblemisespeciallypronunced in a systemcomposed out ofblack box compoents, whichonlydescribetheprovidedandrequiredinterfaces. Whichprovidedservicecallswhichrequiredservice? The dependencyisunknown. Itmightbethecasethat a providedservicedoes not userequiredservicesat all. Itmightbethecasethat a providedserviceusesmanyrequiredservices. Thisis not visiblefromtheinterfacedescriptionbythecomponentdevelopers
Onlyfourrepresentativeapproaches- cheungrequiresthewholesystemtobesetupandmeasured, thisis not desirable- hamletisdifficult- reussnerandcheung do not deal withtheissueandassumetheprobabilitiesasgivenorignorethembecausetheyfocus on a singlecomponent.
Correct y>5!Useannotationsforloop? Multiple internalactions?Correctfailureprobabilitiesfor P2 and P3
a retail chain to handle its sales and manage its inventory dataservice-orientedsystemwithcustomerandproviderfocus on theservicebookSale() oftheInventorycomponent- retail solution clients invoke this operation at the end of each salesprocess in order to update the stock information
If we set a goal of 99.99% for the bookSale() reliability, the gure shows thatthis goal is reached with a stock update failure probability of 10-e6 and at most 98items. If the failure probability rises to 2-e6 the goal is only reached with anumber of items smaller than 50.

Parameter Dependencies for Component Reliability Specifications

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie Parameter Dependencies for Component Reliability Specifications

Ähnlich wie Parameter Dependencies for Component Reliability Specifications (20)

Mehr von Heiko Koziolek

Mehr von Heiko Koziolek (17)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Parameter Dependencies for Component Reliability Specifications

Hinweis der Redaktion