DOCSLIB.ORG

CMSIS Vs POSIX

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
CMSIS Vs POSIX IoT Device Platform - ARTIK & IoT Protocols - 2017. 11. 8 최 욱 S/W 센터 (반도체연구소) 삼성전자 1 1 Outline 1. The Era of IoT 2. IoT Value 3. IoT Architecture 4. Samsung ARTIK 5. IoT Platform 6. IoT Protocols 2 4차 산업혁명… 확산 & 전환 3 Amazon ….. 4 Amazon ….. ■ Amazon Go 5 Tesla … ■ Electric Car manufacturer .. That is all? Gigafactory in Nevada, US Solar roof tile from Solarcity 6 Tesla … ■ Unveiling a new solar panel 7 IoT Hype Cycle Gartner Hyper Cycle 8 The Era of IoT - Why Now? ■ Internet Connectivity Evolution From Human-centric to Device-centric 9 The Era of IoT – IIoT & CIoT [Ref] Talk on Industrial Internet of Things @ Intelligent systems tech forum 2014 10 IoT Value – Moore’s Law ■ Gordon Moore predicted that transistor density is doubled every 2 years ■ Moore’s law has been driving IoT evolution from technical perspective… Performance Cost Moore’s Law - A logarithmic scale on the Y-axis processor evolution is following Moore’s law Mobile devices and machine-to-machine (M2M) communication modules are following similar performance and cost curves!!! Hardware miniaturization, decreasing sensor costs, and ambient device connectivity 11 IoT Value – Metcalfe’s Law ■ Targeting a value-driven business to meet its growth expectations ■ The network value grows by “the square of the number of network nodes” while costs follow a more or less linear function (by Bob Metcalfe, 3Com co-founder) N: # of services M: # of devices MetCalfe’s Law Metcalfe’s law is really about network growth, value creation, and customer acquisition rather than about technological innovation 12 IoT Conceptual Architecture ■ Layered architecture consisting of Application, Network, Edge, and Perception layers Clouds Data Application Layer Analytics Services Internet Network Layer High-value devices Gateway/Hub Edge Layer Things Perception Layer (Sensors, Intelligence Appliances…) Constrained devices 13 IoT Use Case Scenario - What a Diverse! ■ Various device architectures, service scenarios and use cases! – Various functions, standards, protocols, APIs ■ One platform dominates all, possible or not possible? – Flexible platform architecture for heterogeneity 14 IoT Platforms – Eco-system ■ IoT is a biz area that creates value out of data collected from “everything connected” must provide various connectivity & data collection technology and eco-system People Eco-system Things Connection with 데이터 various things, env. Internet of Everything !! How can we get everything connected and get some meaningful value out of it? 15 Types of IoT Platforms Cloud Platform Cloud Services Communications Storage / Database AI Analytics Device Management Edge Platform Edge Computing Edge Intelligence Security Gateway Data Collection Security of Messaging Communications Device Platform Data Gathering People & Device & Controllers Connectivity Things BSP Ecosystem 16 Platform Definition ■ Platform Technology (from Wikipedia) – “제품” 개발을 가능하게 하는 기술이나, 현재 또는 미래의 개발을 지원하는 프로세스 17 17/8 Open Platform ■ 필요기능의 통합 플랫폼 개발의 끝이 아니다! – “계속적으로 유용”하고 사용자 친화적인 경험 제공 ■ 어떠한 플랫폼도 똑같이 만들어지지 않는다! – 훨씬 더 강력하고 유용하며 “인기 있는 플랫폼”이 있기 마련 ■ 고객을 알아야 강력한 Platform을 만든다! – 플랫폼 오픈화를 통한 “소통 채널” 극대화! Do you know What your customers want? Evangelize Platform = “Technology + Ecosystem” Platform 사용자 Ecosystem = “Community + Environment” Feedbacks Promote Evangelize Feedback 사용자 + Contributors + Partners Contribute Collaborate Evangelize Contributors Partners 18 Prospective IoT SW Developers ■ Current status of SW development resources - Android developers > Web developers >> Embedded developers 19 Samsung IoT ARTIK Family ■ Support E2E IoT use case scenario from sensor device to cloud Clouds 4xCortex-A9/GPU 8xCortex-A53/GPU 512MB|1GB/4GB 1GB/4GB ARTIK 5X0 ARTIK 710 Rich devices ARTIK 05x (WiFi) Cortex-R4/ 1.4MB/8MB ARTIK 030 (ZigBee) ARTIK 020 (BLE) Constrained Cortex-M4/ Cortex-M4/ devices 32KB/256KB 32KB/256KB [Ref.] https://www.artik.io 20 ARTIK Key Differentiations 21 ARTIK Security ■ Providing differentiated end-to-end security solution ■ Proven security technologies combining HW and SW security [Ref.] https://www.tizen.org/sites/default/files/event/a1_tdc15_artik_-_the_ultimate_platform_solution_for_iot.pdf 22 ARTIK Cloud ■ Connect devices to be analyzed and visualized anytime, anywhere! [Ref.] https://www.tizen.org/sites/default/files/event/a1_tdc15_artik_-_the_ultimate_platform_solution_for_iot.pdf 23 Platform Requirements AS-IS TO-BE • Fragmented API • Consistent API - Inconsistent Dev Exp. because of various API concepts - Providing consistent & developer friendly API & styles Excellent Dev. Exp. to increase usability, productivity, Decreasing usability, productivity, accessibility accessibility • Coarse-grained Build Configurability • Fine-grained Build Configurability - Impossible image build with features tailored only for - Providing build-time feature configurability for OS, device spec. or user-specific use cases network stack, connectivity, Services Over featuring and unnecessary memory usage Optimal memory footprint Already read the sensor Easy to develop services data. How do I upload it using one set of to the Cloud? consistent APIs !!! ARK Platform Device ML BP Security Device ML BP Security Platform API call ARK API Release 24 Platform Requirements . ARTIK device use-case requirement specific image build . Build-time optimal memory footprint by selecting necessary features for OS, Network Stack, Connectivity, Service Framework, etc. Platform Device-specific Memory Footprint - Consisting of component modules: OS, Network Stack , Service Framework, Protocols, Lib. [Low-End] 020 No Thread OS BLE Image CoAP App Sensor Cloud Footprint: ~수십KB Frw Frw Frw GPIO …. ML Lib IoTivity LWM2M [Mid-End] Multi Thread OS 053 Build-time WiFi Configuration CoAP Image CoAP IP HTTP UDP Footprint: ~수백KB GPIO PWM …. BLE Wi-Fi MQTT [High-End] Multi Thread OS WiFi CoAP Image OS TCP/UDP Footprint: ~수천KB GPIO …. 25 Characteristics of TizenRT ■ RTOS-based lightweight platform ■ Fit into constrained devices with Cortex-M/R MPU and less than 2 MB RAM and 16 MB Flash. ■ Cannot load additional modules at runtime ■ POSIX API, BSD Socket API, Shell, and Kconfig build configuration ■ Adopt lightweight JavaScript environment that consists of JerryScript and IoT.js ■ Public open: May 10, 2017 https://github.com/Samsung/TizenRT 26 Platform API Classification ■ Proprietary vs. POSIX - Proprietary (Custom API): not compatible with other OSs - POSIX (Open API): IEEE Standard OS Interface (Linux/Windows/iOS/TizenRT) Ex Advantages Disadvantages Examples • Small Memory Size • No code compatibility and • FreeRTOS • Fast Execution reusability (Esp. Linux-based code • RIOT Proprietary • Quick Interrupt Response reuse) • Zephyr API-based - Customer app. redevelopment - Retraining for new platform • Code compatibility and reuse • Real-time Options • ThreadX - existing Linux code reuse Unpredictable interrupt latency & • QNX POSIX - Almost zero porting effort jitter • VxWorks API-based • Existing Linux • Slow Booting Time • Integrity customer/developer-oriented • Large Memory Size • LynxOS • TizenRT 27 TizenRT Architecture ■ NuttX-based RTOS, called TinyAra ■ Consisting of OS, Core components, framework, and application layers ■ IPv4/IPv6 network stack, file system, lightweight database, device monitor, and IoT protocols (IoTivity, MQTT, CoAP, and LWM2M) https://source.tizen.org/documentation/tizen-rt 28 MQTT (Message Queue Telemetry Transport) Official web site : http://mqtt.org M2Mqtt project : http://www.m2mqtt.net Mosquitto : http://mosquitto.org HiveMQ : http://www.hivemq.com MQTT An implementer’s perspective : http://bit.ly/1koMZLF MQTT Another implementer’s perspective : http://bit.ly/1rHDnAN 29 Characteristics ■ Easy Messaging Protocol ■ Minimal Overhead ■ Data agnostic ■ Publish / Subscribe ■ Push instead Pull ■ Reliable even when used with unreliable networks ■ Constrained Devices ■ Low bandwidth, high latency 30 MQTT Architecture ■ Broker-based communications Publisher Subscriber Broker (Source) (Sink) Subscribe (topic) Publish (topic, info) Publish (topic, info) 31 MQTT Brokering Basic Terms ■ Broker: The broker accepts messages from clients and then delivers them to any interested clients. – Key component of MQTT ■ Client: A “device” that either publishes a message to a topic, subscribes to a topic, or both ■ Topic: A namespace (or place) for messages on the broker. Clients subscribe and publish to a topic ■ Publish: A client sending a message to the broker, using a topic name ■ Subscribe: A client tells the broker which topics interest it. Once subscribed, the broker sends messages published to that topic. A client can subscribe to multiple topics ■ Unsubscribe: Tell the broker you are bored with this topic. In other words, the broker will stop sending messages on this topic. 32 MQTT Advantages in IoT . MQTT packet can be as small as 2 bytes compared to HTTP. MQTT uses binary messages to exchange information with a low overhead . Compared to HTTP which requires multiple POST actions to distribute a message to more than one client, MQTT distributes a message, or, only to a client interested . MQTT is inherently 1 to many communication . Publish-subscriber paradigm in contrast to HTTP based on request/response paradigm . Asynchronous protocol, that means that it does not block the client while it waits for the message no need to be connected at the same time (server & Client). HTTP protocol, that is mainly a synchronous protocol . Highly scalable 33 MQTT QoS ■ MQTT client sets QoS and broker honors the QoS level on each client end
Load more

Recommended publications
  • Chapter 1. Origins of Mac OS X
    1 Chapter 1. Origins of Mac OS X "Most ideas come from previous ideas." Alan Curtis Kay The Mac OS X operating system represents a rather successful coming together of paradigms, ideologies, and technologies that have often resisted each other in the past. A good example is the cordial relationship that exists between the command-line and graphical interfaces in Mac OS X. The system is a result of the trials and tribulations of Apple and NeXT, as well as their user and developer communities. Mac OS X exemplifies how a capable system can result from the direct or indirect efforts of corporations, academic and research communities, the Open Source and Free Software movements, and, of course, individuals. Apple has been around since 1976, and many accounts of its history have been told. If the story of Apple as a company is fascinating, so is the technical history of Apple's operating systems. In this chapter,[1] we will trace the history of Mac OS X, discussing several technologies whose confluence eventually led to the modern-day Apple operating system. [1] This book's accompanying web site (www.osxbook.com) provides a more detailed technical history of all of Apple's operating systems. 1 2 2 1 1.1. Apple's Quest for the[2] Operating System [2] Whereas the word "the" is used here to designate prominence and desirability, it is an interesting coincidence that "THE" was the name of a multiprogramming system described by Edsger W. Dijkstra in a 1968 paper. It was March 1988. The Macintosh had been around for four years.
    [Show full text]
  • High Speed Data Link
    High Speed Data Link Vladimir Stojanovic liheng zhu Electrical Engineering and Computer Sciences University of California at Berkeley Technical Report No. UCB/EECS-2017-72 http://www2.eecs.berkeley.edu/Pubs/TechRpts/2017/EECS-2017-72.html May 12, 2017 Copyright © 2017, by the author(s). All rights reserved. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission. University of California, Berkeley College of Engineering MASTER OF ENGINEERING - SPRING 2017 Electrical Engineering and Computer Science Physical Electronics and Integrated Circuits Project High Speed Data Link Liheng Zhu This Masters Project Paper fulfills the Master of Engineering degree requirement. Approved by: 1. Capstone Project Advisor: Signature: __________________________ Date ____________ Print Name/Department: Vladimir Stojanovic, EECS Department 2. Faculty Committee Member #2: Signature: __________________________ Date ____________ Print Name/Department: Elad Alon, EECS Department Capstone Report Project High Speed Data Link Liheng Zhu A report submitted in partial fulfillment of the University of California, Berkeley requirements of the degree of Master of Engineering in Electrical Engineering and Computer Science March 2017 1 Introduction For our project, High-Speed Data Link, we are trying to implement a serial communication link that can operate at ~25Gb/s through a noisy channel. We decided to build a parameterized library to allow individual user to set up his/her own parameters according to the project specifications and requirements.
    [Show full text]
  • THE FUTURE of HOME NETWORKING the Impact of Wi-Fi, Remote UI and Open Source Stacks on Service Provider Network Architecture
    THE FUTURE OF HOME NETWORKING The Impact of Wi-Fi, Remote UI and Open Source Stacks on Service Provider Network Architecture Business Integration with Clarity The Future of Home Networking | pureIntegration Table of Contents 1 Introduction ................................................................................................. 2 2 Proposed Evolutions .................................................................................... 3 Authentication and WebUI .............................................................................................................. 5 Self-Healing/Diagnostic ................................................................................................................... 6 Security and Content Protection ..................................................................................................... 6 3 Gateway design impact ................................................................................ 7 4 CPE and IoT devices design impact ............................................................... 8 5 Proposed development and integration approach ....................................... 9 Phase 1: Interconnection tests with RDK-B or OpenWrt on Raspberry PI ...................................... 9 Phase 2: Authentication & Remote Management development on Raspberry PI .......................... 9 Phase 3: Port on Production Gateway ............................................................................................ 9 Phase 4: End to End Integration ...................................................................................................
    [Show full text]
  • Status of High Level Architecture Real Time Platform Reference Federation
    STATUS OF HIGH LEVEL ARCHITECTURE REAL TIME PLATFORM REFERENCE FEDERATION OBJECT MODEL (RPR FOM) Peter Ryan1, Peter Ross1, Will Oliver1, and Lucien Zalcman2 1Air Operations Division, Defence Science & Technology Organisation (DSTO), 506 Lorimer St, Fishermans Bend, Melbourne, Victoria 3001. Email: [email protected] 2Zalcman Consulting. Email [email protected] ABSTRACT Several advanced distributed simulation architectures and protocols are currently in use to provide simulation interoperability among Live, Virtual, and Constructive (LVC) simulation systems. Distributed Interactive Simulation (DIS) and High Level Architecture (HLA) are the most commonly used protocols/architectures in the simulation community. HLA is a general purpose architecture for distributed computer simulation systems. To enable HLA federates to interoperate with DIS systems, the Real Time Platform Reference Federation Object Model (RPR FOM) was developed. The RPR FOM defines HLA classes, attributes and parameters that are appropriate for real-time, platform-level simulations. This paper provides a discussion of the current interoperability standards, an update on the status of the RPR FOM, and the implications for Australia. 1. INTRODUCTION Advanced Distributed Simulation (ADS) protocols and architectures were created so that various Live-Virtual- Constructive (LVC) systems could interoperate with each other in a simulated game or exercise in the same synthetic battlespace [1]. The simulation nodes may be collocated or may be geographically remote from each other. Interoperability among such LVC systems can be improved using a specifically designed set of predefined interoperability standards. Such predefined sets of interoperability standards are commonly referred to as Modelling and Simulation Standards Profiles (such as the NATO Modelling and Simulation Standards Profile [2]).
    [Show full text]
  • View on 5G Architecture
    5G PPP Architecture Working Group View on 5G Architecture Version 3.0, June 2019 Date: 2019-06-19 Version: 3.0 Dissemination level: Public Consultation Abstract The 5G Architecture Working Group as part of the 5G PPP Initiative is looking at capturing novel trends and key technological enablers for the realization of the 5G architecture. It also targets at presenting in a harmonized way the architectural concepts developed in various projects and initiatives (not limited to 5G PPP projects only) so as to provide a consolidated view on the technical directions for the architecture design in the 5G era. The first version of the white paper was released in July 2016, which captured novel trends and key technological enablers for the realization of the 5G architecture vision along with harmonized architectural concepts from 5G PPP Phase 1 projects and initiatives. Capitalizing on the architectural vision and framework set by the first version of the white paper, the Version 2.0 of the white paper was released in January 2018 and presented the latest findings and analyses of 5G PPP Phase I projects along with the concept evaluations. The work has continued with the 5G PPP Phase II and Phase III projects with special focus on understanding the requirements from vertical industries involved in the projects and then driving the required enhancements of the 5G Architecture able to meet their requirements. The results of the Working Group are now captured in this Version 3.0, which presents the consolidated European view on the architecture design. Dissemination level: Public Consultation Table of Contents 1 Introduction........................................................................................................................
    [Show full text]
  • MURAC: a Unified Machine Model for Heterogeneous Computers
    UNIVERSITY OF CAPE TOWN MURAC: A unified machine model for heterogeneous computers by Brandon Kyle Hamilton UniversityA thesis submitted of inCape fulfillment Town for the degree of Doctor of Philosophy in the Faculty of Engineering & the Built Environment Department of Electrical Engineering February 2015 The copyright of this thesis vests in the author. No quotation from it or information derived from it is to be published without full acknowledgement of the source. The thesis is to be used for private study or non- commercial research purposes only. Published by the University of Cape Town (UCT) in terms of the non-exclusive license granted to UCT by the author. University of Cape Town ABSTRACT MURAC: A unified machine model for heterogeneous computers by Brandon Kyle Hamilton February 2015 Heterogeneous computing enables the performance and energy advantages of multiple distinct processing architectures to be efficiently exploited within a single machine. These systems are capable of delivering large performance increases by matching the applications to architectures that are most suited to them. The Multiple Runtime- reconfigurable Architecture Computer (MURAC) model has been proposed to tackle the problems commonly found in the design and usage of these machines. This model presents a system-level approach that creates a clear separation of concerns between the system implementer and the application developer. The three key concepts that make up the MURAC model are a unified machine model, a unified instruction stream and a unified memory space. A simple programming model built upon these abstractions provides a consistent interface for interacting with the underlying machine to the user application.
    [Show full text]
  • Mobile and Residential INEA Wi-Fi Hotspot Network Bartosz Musznicki, Karol Kowalik, Piotr Kołodziejski, and Eugeniusz Grzybek
    PAPER INVITED TO 13TH INTERNATIONAL SYMPOSIUM ON WIRELESS COMMUNICATION SYSTEMS 2016, 20–23 SEPTEMBER 2016, POZNAN,´ POLAND 1 Mobile and Residential INEA Wi-Fi Hotspot Network Bartosz Musznicki, Karol Kowalik, Piotr Kołodziejski, and Eugeniusz Grzybek INEA, Poznan,´ Poland {bartosz.musznicki, karol.kowalik, piotr.kolodziejski, eugeniusz.grzybek}@inea.com.pl Abstract—Since 2012 INEA has been developing and expand- in Figure 1, which shows the changes in the number of users ing the network of IEEE 802.11 compliant Wi-Fi hotspots (access throughout an average day. Each data point corresponds to points) located across the Greater Poland region. This network a mean value obtained in the period of one month (further consists of 330 mobile (vehicular) access points carried by public buses and trams and over 20,000 fixed residential hotspots discussed in Section II-D). As in every graph in the paper, distributed throughout the homes of INEA customers to provide confidence intervals (error bars) present the standard deviation Internet access via the “community Wi-Fi” service. Therefore, of a data point. The graph for mobile network shows highest this paper is aimed at sharing the insights gathered by INEA numbers of users in the morning and in the afternoon what throughout 4 years of experience in providing hotspot-based corresponds to the busiest commuting hours. Stationary net- Internet access. The emphasis is put on daily and hourly trends in order to evaluate user experience, to determine key patterns, work, though, exhibits the highest usage in the evening what and to investigate the influences such as public transportation apparently relates to Internet activities performed at home.
    [Show full text]
  • Gate-Level Leakage Assessment and Mitigation
    Gate-level Leakage Assessment and Mitigation Tarun Kathuria Thesis submitted to the Faculty of the Virginia Polytechnic Institute and State University in partial fulfillment of the requirements for the degree of Master of Science in Computer Engineering Patrick R. Schaumont, Chair Cameron D. Patterson Xun Jian June 26, 2019 Blacksburg, Virginia Keywords: Side-channel leakage, Countermeasures, Power analysis attacks Copyright 2019, Tarun Kathuria Gate-level Leakage Assessment and Mitigation Tarun Kathuria (ABSTRACT) Side-channel leakage, caused by imperfect implementation of cryptographic algorithms in hardware, has become a serious security threat for connected devices that generate and process sensitive data. This side-channel leakage can divulge secret information in the form of power consumption or electromagnetic emissions. The side-channel leakage of a crytographic device is commonly assessed after tape-out on a physical prototype. This thesis presents a methodology called Gate-level Leakage Assessment (GLA), which evaluates the power-based side-channel leakage of an integrated circuit at design time. By combining side-channel leakage assessment with power simulations on the gate-level netlist, GLA is able to pinpoint the leakiest cells in the netlist in addition to assessing the overall side-channel vulnerability to side-channel leakage. As the power traces obtained from power simulations are noiseless, GLA is able to precisely locate the sources of side-channel leakage with fewer measurements than on a physical prototype. The thesis applies the methodology on the design of a encryption co-processor to analyze sources of side-channel leakage. Once the gate-level leakage sources are identified, this thesis presents a logic level replacement strategy for the leakage sources that can thwart side-channel leakage.
    [Show full text]
  • Integrating E Verification IP in a VMM Testbench
    Integrating e Verification IP in a VMM Testbench JL Gray Verilab [email protected] Adiel Khan Synopsys [email protected] 30 March 2010 ABSTRACT Modern testbenches often consist of components drawn from multiple languages. In many of these cases, multi-language and multi-methodology interaction is not well defined. In this paper, we will demonstrate the use of e verification components (eVCs) in a SystemVerilog/VMM testbench. Several complex issues arise when using SystemVerilog as the “primary” language. Initial simulator engine synchronization, random generation ordering, timing problems caused by program blocks, and methodology synchronization between the VMM and eRM will all be discussed. Copyright © 2010 Verilab, Inc. All rights reserved. Integrating e Verification IP in a VMM Testbench Contents 1 Overview ................................................................................................................... 3 1.1 Background .......................................................................................................... 3 1.2 Terminology ......................................................................................................... 4 1.3 Other Useful Terminology ................................................................................... 4 2 Challenges ................................................................................................................. 4 2.1 Method Ports ....................................................................................................... 4 2.2
    [Show full text]
  • The Journal for the International Ada Community
    TThehe journaljournal forfor thethe internationalinternational AdaAda communitycommunity AdaAda UserUser Volume 41 Journal Number 1 Journal March 2020 Editorial 3 Quarterly News Digest 4 Conference Calendar 21 Forthcoming Events 29 Anniversary Articles J. Barnes From Byron to the Ada Language 31 C. Brandon CubeSat, the Experience 36 B.M. Brosgol How to Succeed in the Software Business while Giving Away the Source Code: The AdaCore Experience 43 Special Contribution J. Cousins ARG Work in Progress IV 47 Proceedings of the Workshop on Challenges and New Approaches for Dependable and Cyber-Physical Systems of Ada-Europe 2019 L. Nogueira, A. Barros, C. Zubia, D. Faura, D. Gracia Pérez, L.M. Pinho Non-functional Requirements in the ELASTIC Architecture 51 Puzzle J. Barnes Forty Years On and Going Strong 57 Produced by Ada-Europe Editor in Chief António Casimiro University of Lisbon, Portugal [email protected] Ada User Journal Editorial Board Luís Miguel Pinho Polytechnic Institute of Porto, Portugal Associate Editor [email protected] Jorge Real Universitat Politècnica de València, Spain Deputy Editor [email protected] Patricia López Martínez Universidad de Cantabria, Spain Assistant Editor [email protected] Kristoffer N. Gregertsen SINTEF, Norway Assistant Editor [email protected] Dirk Craeynest KU Leuven, Belgium Events Editor [email protected] Alejandro R. Mosteo Centro Universitario de la Defensa, Zaragoza, Spain News Editor [email protected] Ada-Europe Board Tullio Vardanega (President) Italy University
    [Show full text]
  • Model-Driven Distributed Simulation Engineering
    Proceedings of the 2019 Winter Simulation Conference N. Mustafee, K.-H.G. Bae, S. Lazarova-Molnar, M. Rabe, C. Szabo, P. Haas, and Y.-J. Son, eds. MODEL-DRIVEN DISTRIBUTED SIMULATION ENGINEERING Paolo Bocciarelli Andrea D’Ambrogio Andrea Giglio Emiliano Paglia Department of Enterprise Engineering University of Rome Tor Vergata Rome, Italy ABSTRACT Simulation-based analysis is widely recognized as an effective technique to support verification and validation of complex systems throughout their lifecycle. The inherently distributed nature of complex systems makes the use of distributed simulation approaches a natural fit. However, the development of a distributed simulation is by itself a challenging task in terms of effort and required know-how. This tutorial introduces an approach that applies highly automated model-driven engineering principles and standards to ease the development of distributed simulations. The proposed approach is framed around the development process defined by the DSEEP (Distributed Simulation Engineering and Execution Process) standard, as applied to distributed simulations based on the HLA (High Level Architecture), and is focused on a chain of automated model transformations. A case study is used in the tutorial to illustrate an example application of the proposed model-driven approach to the development of an HLA-based distributed simulation of a space system. 1 INTRODUCTION The development of complex systems strongly benefits from the adoption of quantitative analysis techniques that enable an early evaluation of the system behavior, so to assess, before starting implementation or maintenance activities, whether or not the to-be system is going to satisfy the stakeholder requirements and constraints. In this context, simulation-based techniques may be effectively introduced to enact the design-time evaluation of various structural and/or behavioral properties of the system under study.
    [Show full text]
  • Software Maintenance Maturity Model (Smmm): the Software Maintenance Process Model
    Software Maintenance Maturity Model (SMmm): The software maintenance process model Alain April1, Jane Huffman Hayes* ,†,2, Alain Abran1, and Reiner Dumke3 1Department of Software Engineering, Université du Québec, École de Technologie Supérieure, Canada 2Department of Computer Science, University of Kentucky, U.S.A. 3Department of Informatik, Otto von Guericke Universtity of Magdeburg, Germany. SUMMARY We address the assessment and improvement of the software maintenance function by proposing improvements to the software maintenance standards and introducing a proposed maturity model for daily software maintenance activities: Software Maintenance Maturity Model (SMmm). The software maintenance function suffers from a scarcity of management models to facilitate its evaluation, management, and continuous improvement. The SMmm addresses the unique activities of software maintenance while preserving a structure similar to that of the CMMi©4 maturity model. It is designed to be used as a complement to this model. The SMmm is based on practitioners’ experience, international standards, and the seminal literature on software maintenance. We present the model’s purpose, scope, foundation, and architecture, followed by its initial validation. Copyright © 2004 John Wiley & Sons, Ltd. J. Softw. Maint. And Evolution 2004; No. of Figures: 4. No. of Tables: 7. No. of References: 117. KEY WORDS: software maintenance; process improvement; process model; maturity model *Correspondence to: Jane Hayes, Computer Science, Laboratory for Advanced Networking, University of Kentucky, 301 Rose Street, Hardymon Building, Lexington, Kentucky 40506-0495 USA. †E-mail: [email protected] Contract/grant sponsor: none 1. INTRODUCTION Corporations that rely on revenues from developing and maintaining software now face a new, globally competitive market with increasingly demanding customers.
    [Show full text]