DOCSLIB.ORG

CHALLENGES in IOT TESTING © Vadim © Vadim Makhorov

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

CHALLENGES IN IOT TESTING © Vadim © Vadim Makhorov Ina Schieferdecker TestNet, May 11, 2016 TALKING PLANTS, ANIMALS AND MORE http://www.iot-a.eu/public 3 © Fraunhofer FOKUS IOT MARKET FORECAST 4 © Fraunhofer FOKUS FURTHER FORECASTS Connected Mobiles worldwide Source: Cisco Global Mobile Traffic Forecast Update, Gartner Global data streams in the Internet per Second in Terabyte Source: ITU ICT Facts and Figures 2015-2020 5 © Fraunhofer FOKUS IOT REFERENCE MODEL (ONE OF MANY) 6 © Fraunhofer FOKUS NEW ARCHITECTURAL PARADIGM Today Upcoming Hierarchical Orchestrated ERP MES SCADA PLC I/O Openess, Dynamicity, Scalability 7 CRITICALITY IMPLY HIGH QUALITY REQUIREMENTS »Implementation of real-time enabled CPS solutions will place high demands on the availability of services and network infrastructure in terms of space, technical quality and reliability.« In: Securing the future of German manufacturing industry. Recommendations for implementing the strategic initiative INDUSTRIE 4.0, Forschungsunion, acatech, Apr. 2013. Priorities of Quality, Time and Costs In: Stand und Trends der Qualitätssicherung von vernetzten eingebetteten Systemen, Fraunhofer FOKUS Studie, Aug. 2014 8 © Fraunhofer FOKUS ANYTHING NEW IN IOT TESTING ?! Similar Protocol stacks Protocol testing IETF-based: CoAP, MQTT, etc. Conformance IEC-based: OPC-UA Interoperability ITU-based: M2M Performance Application frameworks Software testing Eclipse: Kura, Scada, etc. Component testing Many others Integration testing System testing Different Security Security testing ISO: common criteria Risk-oriented testing Mitre: CWE list Fuzz testing Others Online testing Data Data quality Semantic real-time data 9 © Fraunhofer FOKUS FURTHER ASPECTS IoT solutions often are … IoT test solutions need to … 1. in harsh, unreliable environments Integrate simulators for environmental conditions Systematically determine reference 2. in highly dynamic configurations with configurations large number of – typically diverse – sensors and actuators with open Adjust and scale test configurations interfaces and dynamically 3. In resource-constrained Be a real-time system by itself environments Support test scenarios for hybrid systems (both events and streams) Test platform for the Internet of Things embedded virtualized 10 © Fraunhofer FOKUS INTEGRATION OF SEVERAL TESTING APPROACHES Software System Testing Testing Protocol IoT Testing Security Testing Testing Test Automation 11 © Fraunhofer FOKUS CHALLENGE TEST AUTOMATION TTCN-3 is the Testing and Test Control Notation Internationally standardized testing language for formally defining test scenarios. Designed purely for testing testcase Hello_Bob () { p.send(“How do you do?“); alt { []p.receive(“Fine!“); {setverdict( pass )}; [else] {setverdict( inconc )} //Bob asleep! } } 12 DESIGN PRINCIPLES OF TTCN-3 One test technology for different tests Distributed, platform-independent testing Integrated graphical test development, documentation and analysis Adaptable, open test environment Areas of Testing Regression testing Conformance and functional testing Interoperability and integration testing Real-time, performance, load and stress testing Security testing 13 TTCN-3 EXECUTION API / Communication Software / Invocations Tester SUT System TTCN-3 API / Communication Software / Invocations 14 A TTCN-3 TEST SYSTEM Test System User TM: Management TL: Logging TE – TTCN-3 Executable TCI TM – Test Management TL – Test Logging TE CD – Codec Handling CD: Codec CH: Component CH – Component Handling TRI SA – System Adapter SA: System Adapter PA: Platform Adapter PA – Platform Adapter System Under Test (SUT) SUT – System Under Test ETSI ES 201 873-1 TTCN-3 Core Language (CL) ETSI ES 201 873-5 TTCN-3 Runtime Interface (TRI) ETSI ES 201 873-6 TTCN-3 Control Interfaces (TCI) 16 IMPLEMENTATION ATS Test System TE + Communication / SUT Invocation 17 TTCN-3 DOMAINS: TELECOM Industrial use Big companies with hundreds of TTCN-3 engineers: Ericsson, Nokia, Siemens, Motorola large distribution among SMEs Standardization bodies Standardized test suites: ETSI / 3GPP (LTE)/ OMA / TETRA and its members IMS performance benchmarking: Intel, HP, BT and others Test tool manufacturer: Commercial Tektronix, Catapult, Nexus, R&S, Spirent, … Free tools by Eclipse and academics Certification program based on TTCN-3: e.g. WiMax forum 19 TEST SYSTEM EXAMPLE: OMA SUPL Secure User Plane Location Protocol Single MTC controls e.g.: UlpPort (Lup interface) IpcPort (IP configuration) TTCN-3 MTC MTC BSF DNS smsPort used for SMS Executable UtpPort for upper tester commands ssc nwcipi ipc ulpbsf dns sms sms utp IpiPort (IP information, e.g. release) NwcPort: network bearer control, SUT e.g. handover trigger Adapter SscPort: satellite simulation control, e.g. scenario trigger MT_SMS, WAP_Push, SIP_Push TLS (PSK) SMS Upper Satellite Tester TCP/UDP/IPTCP/UDP/IP Simulator Adapter e.g. text Network Bearer SUT Upper IUT ((SUPLSUPL Tester (SUPL Implementation) Terminal)Terminal) 20Server TTCN-3 DOMAINS: AUTOMOTIVE Cockpit systems CD Changer Edutainment Amplifier Head units Head Unit / Tuner Tester MOST Bus Car-to-X communication Car-to-car, car-to-roadside, car-to-backbone Speaker Autonomic driving Telematics Applications in the Cockpit • Audio (CD / Radio), Video • Telephone, SMS • Navigation • Speech recognition • User interface for body electronic 22 CHALLENGE EMBEDDED SYSTEMS • Interfaces to support distributed • Concepts to deal with synchronous scheduling of Test System User time and continuous components signals • Interfaces to support transmission of • Concept that allow continuous signals between TM: Test Management TL: Test Loggingadvanced control flow components TCI for hybrid system testing CoDec CD: TE: Test Executable CH: Handling Component TRI SA: System Adapter PA: Platform Adapter System Under Test (SUT) • Interfaces to support • Interfaces to support access to time and stimulation with and sampling evaluation of continuous signals 23 TTCN-3 EMBEDDED MODES accelerate constant brake Xn until [g1] until [g2] yn SIGNAL GENERATION BUILDING BLOCKS testcase signal_generation() runs on mtcType{ seq{ apply_noise(Throttle, 5.0, 5.0); apply_noise(Throttle, 10.0, 5.0); apply_ramp(Throttle, 10.0, 10.0, 2.0, 3); …} 24 PedalPositions v_act 2 1 <phi_Acc, phi_Brake> <phi_Acc, v_act ped_min <phi_Brake> <phi_Acc> <phi_Brake> <phi_Acc> <phi_Acc> T_100_Drive(v) T_70_Drive(v) >= >= BrakePedal AccPedal 70 <phi_Acc> INTEGRATION IN ML/SL T_max_Brake boolean boolean 1/30 1/70 BrakePedal AccPedal 1/100 <AccPedal, BrakePedal> <AccPedal, T_des_Brake Mu selection f(u) T_des_Drive <T_des_Drive, T_des_Brake> <T_des_Drive, PedalFlags 2 DesiredTorques // accelerate vehicle until 35 1 // ms and activate ACCS cont{ onentry{v_other.value:= 25.0} phi_acc.value:=80.0; } until{ 1. Introduce a vehicle ahead [v_ego.value > 35.0] { 2. Accelerate the ego vehicle until its phi_acc.value:=0.0; velocity rises to more than 35 m/s. lever_pos.value:= MIDDLE; 3. Activate the cruise control. } 4. The ACC shall switch to the velocity } control mode and the vehicle shall hold the current velocity // wait for several seconds 5. When the vehicle reaches the safe wait(now+10.0); distance to the vehicle ahead the ACC // evaluate shall switch to distance control mode. cont{ 6. The ACC should now adjust the running assert(v_ego.value <= 38.0); } velocity according to the vehicle ahead until{ 7. The safe distance to the vehicle ahead [d_other.value < sd] { ... must be guaranteed. 25 25 AUTOMATED V2X TEST BED Test Execution V2X Test Bed and Tool Suite Test Data Generation (e.g. Traffic Log File Analysis Simulation Data) and Visualization 26 THE SIMTD SET UP IN THE LAB 27 Hier steht die Fußzeile V2X TEST BED ARCHITECTURE template V2XMessage c2xMessage(in id := sid, payload := { protocolVersion := 1, actionID := 100, ICT cancelationFlag := false, LSS generationTime := {t, 0}, validityDuration := 100, IRS referencePosition := {longitude := {isE, protocolMsg := pm } } IVS traffic jam traffic Test Control Elements IVS • Test control with TTworkbench and V2X framework (allow for synchronized stimulation and evaluation of V2X system interaction) • Currently up to 4 IVS and 2 IRS systems to be connected to the test control over Ethernet HM • Optional integration with ICT and other hardware possible I 28 EXAMPLE: WEATHER WARNING • IVS1: Generate situation WiperSystem := { Front := "normal", Rear := "idle" } WiperSystem := { Front := "fast", Rear := "idle" } • IVS2: Check message reception DENM message received ? • IVS2: Check HMI interaction 29 DRIVE C2X REFERENCE TESTS • Compatible with ETSI Standards Example Traffic Jam Ahead Warning (TJAW): • Virtualized Test Environment Tests TJAW with different jam configurations by varying: Tests available for: • number of vehicles in jam • Stationary vehicle warning • velocity of vehicles • Road works warning • distance to EGO • Slow vehicle warning • velocity of EGO • Traffic jam ahead warning • In vehicle signage JAM is simulated by injecting CAM messages • Emergency vehicle warning, for the individual vehicles • Emergency electronic brake lights 30 SIMTD REFERENCE TESTS • 40 Communication tests and test variants CAM variants CAM frequencies, message life time handling etc. DENM variants • 20 Application tests testing event detection, propagation, handling and user Improve Quality notification for several V2X applications • Reference circuit event handling and user notification for several V2X applications • Reference circuit with load
Recommended publications
  • Core Elements of Continuous Testing

    Core Elements of Continuous Testing

    WHITE PAPER CORE ELEMENTS OF CONTINUOUS TESTING Today’s modern development disciplines -- whether Agile, Continuous Integration (CI) or Continuous Delivery (CD) -- have completely transformed how teams develop and deliver applications. Companies that need to compete in today’s fast-paced digital economy must also transform how they test. Successful teams know the secret sauce to delivering high quality digital experiences fast is continuous testing. This paper will define continuous testing, explain what it is, why it’s important, and the core elements and tactical changes development and QA teams need to make in order to succeed at this emerging practice. TABLE OF CONTENTS 3 What is Continuous Testing? 6 Tactical Engineering Considerations 3 Why Continuous Testing? 7 Benefits of Continuous Testing 4 Core Elements of Continuous Testing WHAT IS CONTINUOUS TESTING? Continuous testing is the practice of executing automated tests throughout the software development cycle. It’s more than just automated testing; it’s applying the right level of automation at each stage in the development process. Unlike legacy testing methods that occur at the end of the development cycle, continuous testing occurs at multiple stages, including development, integration, pre-release, and in production. Continuous testing ensures that bugs are caught and fixed far earlier in the development process, improving overall quality while saving significant time and money. WHY CONTINUOUS TESTING? Continuous testing is a critical requirement for organizations that are shifting left towards CI or CD, both modern development practices that ensure faster time to market. When automated testing is coupled with a CI server, tests can instantly be kicked off with every build, and alerts with passing or failing test results can be delivered directly to the development team in real time.
  • Security Analysis for MQTT in Internet of Things

    Security Analysis for MQTT in Internet of Things

    DEGREE PROJECT IN COMPUTER SCIENCE AND ENGINEERING, SECOND CYCLE, 30 CREDITS STOCKHOLM, SWEDEN 2018 Security analysis for MQTT in Internet of Things DIEGO SALAS UGALDE KTH ROYAL INSTITUTE OF TECHNOLOGY SCHOOL OF ELECTRICAL ENGINEERING AND COMPUTER SCIENCE Security analysis for MQTT in Internet of Things DIEGO SALAS UGALDE Master in Network Services and Systems Date: November 22, 2018 Supervisor: Johan Gustafsson (Zyax AB) Examiner: Panos Papadimitratos (KTH) Swedish title: Säkerhet analys för MQTT i IoT School of Electrical Engineering and Computer Science iii Abstract Internet of Things, i.e. IoT, has become a very trending topic in re- search and has been investigated in recent years. There can be several different scenarios and implementations where IoT is involved. Each of them has its requirements. In these type IoT networks new com- munication protocols which are meant to be lightweight are included such as MQTT. In this thesis there are two key aspects which are under study: secu- rity and achieving a lightweight communication. We want to propose a secure and lightweight solution in an IoT scenario using MQTT as the communication protocol. We perform different experiments with different implementations over MQTT which we evaluate, compare and analyze. The results obtained help to answer our research questions and show that the proposed solution fulfills the goals we proposed in the beginning of this work. iv Sammanfattning "Internet of Things", dvs IoT, har blivit ett mycket trenderande ämne inom forskning och har undersökts de senaste åren. Det kan finnas flera olika scenarier och implementeringar där IoT är involverad. Var och en av dem har sina krav.
  • Test-Beds and Guidelines for Securing Iot Products and for Secure Set-Up Production Environments

    Test-Beds and Guidelines for Securing Iot Products and for Secure Set-Up Production Environments

    IoT4CPS – Trustworthy IoT for CPS FFG - ICT of the Future Project No. 863129 Deliverable D7.4 Test-beds and guidelines for securing IoT products and for secure set-up production environments The IoT4CPS Consortium: AIT – Austrian Institute of Technology GmbH AVL – AVL List GmbH DUK – Donau-Universit t Krems I!AT – In"neon Technologies Austria AG #KU – JK Universit t Lin$ / Institute for &ervasive 'om(uting #) – Joanneum )esearch !orschungsgesellschaft mbH *+KIA – No,ia -olutions an. Net/or,s 0sterreich GmbH *1& – *1& -emicon.uctors Austria GmbH -2A – -2A )esearch GmbH -)!G – -al$burg )esearch !orschungsgesellschaft -''H – -oft/are 'om(etence 'enter Hagenberg GmbH -AG0 – -iemens AG 0sterreich TTTech – TTTech 'om(utertechni, AG IAIK – TU Gra$ / Institute for A((lie. Information &rocessing an. 'ommunications ITI – TU Gra$ / Institute for Technical Informatics TU3 – TU 3ien / Institute of 'om(uter 4ngineering 1*4T – 1-Net -ervices GmbH © Copyright 2020, the Members of the IoT4CPS Consortium !or more information on this .ocument or the IoT5'&- (ro6ect, (lease contact8 9ario Drobics7 AIT Austrian Institute of Technology7 mario:.robics@ait:ac:at IoT4C&- – <=>?@A Test-be.s an. guidelines for securing IoT (ro.ucts an. for secure set-up (ro.uction environments Dissemination level8 &U2LI' Document Control Title8 Test-be.s an. gui.elines for securing IoT (ro.ucts an. for secure set-u( (ro.uction environments Ty(e8 &ublic 4.itorBsC8 Katharina Kloiber 4-mail8 ,,;D-net:at AuthorBsC8 Katharina Kloiber, Ni,olaus DEr,, -ilvio -tern )evie/erBsC8 -te(hanie von )E.en, Violeta Dam6anovic, Leo Ha((-2otler Doc ID8 DF:5 Amendment History Version Date Author Description/Comments VG:? ?>:G?:@G@G -ilvio -tern Technology Analysis VG:@ ?G:G>:@G@G -ilvio -tern &ossible )esearch !iel.s for the -2I--ystem VG:> >?:G<:@G@G Katharina Kloiber Initial version (re(are.
  • An Iot-Based Mobile System for Safety Monitoring of Lone Workers

    An Iot-Based Mobile System for Safety Monitoring of Lone Workers

    IoT Article An IoT-Based Mobile System for Safety Monitoring of Lone Workers Pietro Battistoni * , Monica Sebillo and Giuliana Vitiello LabGis Laboratory, Computer Science Department, University of Salerno, 84084 Fisciano, Italy; [email protected] (M.S.); [email protected] (G.V.) * Correspondence: [email protected] Abstract: The European Agency for Safety and Health at Work considers Smart Personal Protective Equipment as “Intelligent Protection For The Future”. It mainly consists of electronic components that collect data about their use, the workers who wear them, and the working environment. This paper proposes a distributed solution of Smart Personal Protective Equipment for the safety monitoring of Lone Workers by adopting low-cost electronic devices. In addition to the same hazards as anyone else, Lone Workers need additional and specific systems due to the higher risk they run on a work site. To this end, the Edge-Computing paradigm can be adopted to deploy an architecture embedding wearable devices, which alerts safety managers when workers do not wear the prescribed Personal Protective Equipment and supports a fast rescue when a worker seeks help or an accidental fall is automatically detected. The proposed system is a work-in-progress which provides an architecture design to accommodate different requirements, namely the deployment difficulties at temporary and large working sites, the maintenance and connectivity recurring cost issues, the respect for the workers’ privacy, and the simplicity of use for workers and their supervisors. Citation: Battistoni, P.; Sebillo, M.; Keywords: IoT mobile solution; Edge-Computing paradigm; wearable devices; MQTT protocol; safety Vitiello, G. An IoT-Based Mobile monitoring; Smart Personal Protective Equipment; Fog-Computing System for Safety Monitoring of Lone Workers.
  • Leading Practice: Test Strategy and Approach in Agile Projects

    Leading Practice: Test Strategy and Approach in Agile Projects

    CA SERVICES | LEADING PRACTICE Leading Practice: Test Strategy and Approach in Agile Projects Abstract This document provides best practices on how to strategize testing CA Project and Portfolio Management (CA PPM) in an agile project. The document does not include specific test cases; the list of test cases and steps for each test case are provided in a separate document. This document should be used by the agile project team that is planning the testing activities, and by end users who perform user acceptance testing (UAT). Concepts Concept Description Test Approach Defines testing strategy, roles and responsibilities of various team members, and test types. Testing Environments Outlines which testing is carried out in which environment. Testing Automation and Tools Addresses test management and automation tools required for test execution. Risk Analysis Defines the approach for risk identification and plans to mitigate risks as well as a contingency plan. Test Planning and Execution Defines the approach to plan the test cases, test scripts, and execution. Review and Approval Lists individuals who should review, approve and sign off on test results. Test Approach The test approach defines testing strategy, roles and responsibilities of various team members, and the test types. The first step is to define the testing strategy. It should describe how and when the testing will be conducted, who will do the testing, the type of testing being conducted, features being tested, environment(s) where the testing takes place, what testing tools are used, and how are defects tracked and managed. The testing strategy should be prepared by the agile core team.
  • Mqtt-V5.0-Cs02.Pdf

    Mqtt-V5.0-Cs02.Pdf

    MQTT Version 5.0 Committee Specification 02 15 May 2018 Specification URIs This version: http://docs.oasis-open.org/mqtt/mqtt/v5.0/cs02/mqtt-v5.0-cs02.docx (Authoritative) http://docs.oasis-open.org/mqtt/mqtt/v5.0/cs02/mqtt-v5.0-cs02.html http://docs.oasis-open.org/mqtt/mqtt/v5.0/cs02/mqtt-v5.0-cs02.pdf Previous version: http://docs.oasis-open.org/mqtt/mqtt/v5.0/cs01/mqtt-v5.0-cs01.docx (Authoritative) http://docs.oasis-open.org/mqtt/mqtt/v5.0/cs01/mqtt-v5.0-cs01.html http://docs.oasis-open.org/mqtt/mqtt/v5.0/cs01/mqtt-v5.0-cs01.pdf Latest version: http://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.docx (Authoritative) http://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html http://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.pdf Technical Committee: OASIS Message Queuing Telemetry Transport (MQTT) TC Chairs: Brian Raymor ([email protected]), Microsoft Richard Coppen ([email protected]), IBM Editors: Andrew Banks ([email protected]), IBM Ed Briggs ([email protected]), Microsoft Ken Borgendale ([email protected]), IBM Rahul Gupta ([email protected]), IBM Related work: This specification replaces or supersedes: • MQTT Version 3.1.1. Edited by Andrew Banks and Rahul Gupta. 29 October 2014. OASIS Standard. http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html. This specification is related to: • MQTT and the NIST Cybersecurity Framework Version 1.0. Edited by Geoff Brown and Louis-Philippe Lamoureux.
  • Synergy MQTT/TLS AWS Cloud Connectivity Solution

    Synergy MQTT/TLS AWS Cloud Connectivity Solution

    Application Note Renesas Synergy™ Platform Synergy MQTT/TLS AWS Cloud Connectivity Solution Introduction This application note describes IoT Cloud connectivity solution in general, introduces you briefly to IoT Cloud providers, like Amazon Web Services (AWS), and covers the Synergy MQTT/TLS module, its features, and operational flow sequence (Initialization/Data flow). The application example provided in the package uses AWS IoT Core. The detailed steps in this document show first-time AWS IoT Core users how to configure the AWS IoT Core platform to run this application example demonstration. This application note enables you to effectively use the Synergy MQTT/TLS modules in your own design. Upon completion of this guide, you will be able to add the MQTT/TLS module to your own design, configure it correctly for the target application, and write code using the included application example code as a reference and efficient starting point. References to detailed API descriptions, and other application projects that demonstrate more advanced uses of the module, are in the Synergy Software Package (SSP) User’s Manual, which serves as a valuable resource in creating more complex designs. This Synergy MQTT/TLS AWS Cloud Connectivity solution is supported on AE-CLOUD1 and AE-CLOUD2 kits. Required Resources To build and run the MQTT/TLS application example, you need: Development tools and software • e2 studio ISDE v7.5.1 or later, or IAR Embedded Workbench® for Renesas Synergy™ v8.23.3 or later, available at www.renesas.com/synergy/tools . • Synergy Software Package (SSP) 1.7.8 or later (www.renesas.com/synergy/ssp) • Synergy Standalone Configurator (SSC) 7_3_0 or later (www.renesas.com/synergy/ssc) • SEGGER J-link® USB driver (www.renesas.com/synergy/jlinksynergy) Hardware • Renesas Synergy™ AE-CLOUD1 kit (www.renesas.com/synergy/ae-cloud1), which includes Wi-Fi board; and, AE-CLOUD2 kit (www.renesas.com/synergy/ae-cloud2), which includes a Pillar board, Wi-Fi board and BG96 Cellular shield.
  • A Comparison of Iot Application Layer Protocols Through a Smart Parking Implementation

    A Comparison of Iot Application Layer Protocols Through a Smart Parking Implementation

    A Comparison of IoT application layer protocols through a smart parking implementation Paridhika Kayal and Harry Perros {pkayal,hp}@ncsu.edu Computer Science Department North Carolina State University Abstract—Several IoT protocols have been introduced in order to high performance, real-time data sharing or real-time device provide an efficient communication for resource-constrained control. In many cases data is collected for subsequent applications. However, their performance is not as yet well “offline” processing. The WebSocket (WS) standard provides understood. To address this issue, we evaluated and compared bi-directional Web communication and connection four communication protocols, namely, CoAP, MQTT, XMPP, management. WebSocket is a good IoT solution if the devices and WebSocket. For this, we implemented a smart parking application using open source software for these protocols and can afford the WebSocket payload. Other protocols, such as, measured their response time by varying the traffic load. SMQ and CoSIP are also gaining traction. All these protocols Keywords—CoAP, MQTT, XMPP, WebSocket, smart parking, are positioned as real-time publish-subscribe IoT protocols, response time. with support for millions of devices. Depending on how you define “real time” (seconds, milliseconds or microseconds) I. INTRODUCTION and “things” (WSN node, multimedia device, personal An IoT application typically involves a large number of wearable device, medical scanner, engine control, etc.), the deployed and interconnected sensors and gateways. The protocol selection for an application is critical. sensors measure the physical environment and send the data to II. RELATED WORK a gateway. The gateway aggregates the data from various sensors and then sends it to a server/broker.
  • MQTT in Internet of Things

    MQTT in Internet of Things

    International Research Journal of Engineering and Technology (IRJET) e-ISSN: 2395-0056 Volume: 06 Issue: 12 | Dec 2019 www.irjet.net p-ISSN: 2395-0072 MQTT in Internet of Things Shiva Shankar J1, Dr. S. Palanivel2, Dr. S. China Venkateswarlu3, M. Sowmya4 1SDET, QA, Mevatron Solutions Pvt. Limited, Hyderabad, Telangana, India. 2Associate Professor, Dept. of EIE, Annamalai University, Chidambaram, Tamil Nadu, India. 3Professor, Dept. of ECE, Institute of Aeronautical Engineering, Hyderabad, Telangana, India. 4Asst. Professor, Dept. of CSE, Stanley College of Engineering and Technology for Women, Hyderabad, India. ---------------------------------------------------------------------***---------------------------------------------------------------------- Abstract - With the advancements in the technology in (MQTT), Constrained Application Protocol (CoAP), Advanced various areas like Electronics, Communications, Message Queuing Protocol (AMQP), Machine-to-Machine Instrumentation, etc., there is a tremendous change in the (M2M) Communication Protocol , Extensible Messaging and applications as well as appliances that are being produced by Presence Protocol (XMPP),etc., The embedded devices will the Industrial markets all over the world. A new term is coined have constrained resources in terms of memory, named as Internet of Things (IoT) which is a revolution in computational power, battery etc. As a relief, certain light terms of technology. Internet of Things (IoT) is based on a weight protocols such as MQTT, CoAP etc., are being wireless network that connects a huge number of smart developed especially for the devices that are part of Internet objects, products, smart devices, and people. IoT uses of Things network. In this paper, the details of Message standards and protocols that are proposed by different Queuing Telemetry Transportation (MQTT) are presented. standardization organizations in message passing within The Applications of IoT includes Smart Cities, Smart session layer.
  • Chap 3. Test Models and Strategies 3.5 Test Integration and Automation 1

    Chap 3. Test Models and Strategies 3.5 Test Integration and Automation 1

    Chap 3. Test Models and Strategies 3.5 Test Integration and Automation 1. Introduction 2. Integration Testing 3. System Testing 4. Test Automation Appendix: JUnit Overview 1 1. Introduction -A system is composed of components. System of software components can be defined at any physical scope. Component System Typical intercomponent interfaces (locus of (Focus of Integration) (Scope of integration faults) Integration) Method Class Instance variables Intraclass messages Class Cluster Intraclass messages Cluster Subsystem Interclass messages Interpackage messages Subsystem System Inteprocess communication Remote procedure call ORB services, OS services -Integration test design is concerned with several primary questions: 1. Which components and interfaces should be exercised? 2. In what sequence will component interfaces be exercised? 2 3. Which test design technique should be used to exercise each interface? -Integration testing is a search for component faults that cause intercomponent failures. -System scope testing is a search for faults that lead to a failure to meet a system scope responsibility. ÷System scope testing cannot be done unless components interoperate sufficiently well to exercise system scope responsibilities. -Effective testing at system scope requires a concrete and testable system-level specification. ÷System test cases must be derived from some kind of functional specification. Traditionally, user documentation, product literature, line-item narrative requirements, and system scope models have been used. 3 2. Integration Testing -Unit testing focuses on individual components. Once faults in each component have been removed and the test cases do not reveal any new fault, components are ready to be integrated into larger subsystems. -Integration testing detects faults that have not been detected during unit testing, by focusing on small groups of components.
  • Slowtt: a Slow Denial of Service Against Iot Networks

    Slowtt: a Slow Denial of Service Against Iot Networks

    information Article SlowTT: A Slow Denial of Service Against IoT Networks Ivan Vaccari 1,2,* , Maurizio Aiello 1 and Enrico Cambiaso 1 1 Consiglio Nazionale delle Ricerche (CNR), IEIIT Institute, 16149 Genoa, Italy; [email protected] (M.A.); [email protected] (E.C.) 2 Department of Informatics, Bioengineering, Robotics and System Engineering (DIBRIS), University of Genoa, 16145 Genoa, Italy * Correspondence: [email protected]; Tel.: +39-010-6475-215 Received: 18 August 2020; Accepted: 15 September 2020; Published: 18 September 2020 Abstract: The security of Internet of Things environments is a critical and trending topic, due to the nature of the networks and the sensitivity of the exchanged information. In this paper, we investigate the security of the Message Queue Telemetry Transport (MQTT) protocol, widely adopted in IoT infrastructures. We exploit two specific weaknesses of MQTT, identified during our research activities, allowing the client to configure the KeepAlive parameter and MQTT packets to execute an innovative cyber threat against the MQTT broker. In order to validate the exploitation of such vulnerabilities, we propose SlowTT, a novel “Slow” denial of service attack aimed at targeting MQTT through low-rate techniques, characterized by minimum attack bandwidth and computational power requirements. We validate SlowTT against real MQTT services, by considering both plaintext and encrypted communications and by comparing the effects of the attack when targeting different application daemons and protocol versions. Results show that SlowTT is extremely successful, and it can exploit the identified vulnerability to execute a denial of service against the IoT network by keeping the connection alive for a long time.
  • Integration Testing of Object-Oriented Software

    Integration Testing of Object-Oriented Software

    POLITECNICO DI MILANO DOTTORATO DI RICERCA IN INGEGNERIA INFORMATICA E AUTOMATICA Integration Testing of Object-Oriented Software Ph.D. Thesis of: Alessandro Orso Advisor: Prof. Mauro Pezze` Tutor: Prof. Carlo Ghezzi Supervisor of the Ph.D. Program: Prof. Carlo Ghezzi XI ciclo To my family Acknowledgments Finding the right words and the right way for expressing acknowledgments is a diffi- cult task. I hope the following will not sound as a set of ritual formulas, since I mean every single word. First of all I wish to thank professor Mauro Pezze` , for his guidance, his support, and his patience during my work. I know that “taking care” of me has been a hard work, but he only has himself to blame for my starting a Ph.D. program. A very special thank to Professor Carlo Ghezzi for his teachings, for his willingness to help me, and for allowing me to restlessly “steal” books and journals from his office. Now, I can bring them back (at least the one I remember...) Then, I wish to thank my family. I owe them a lot (and even if I don't show this very often; I know this very well). All my love goes to them. Special thanks are due to all my long time and not-so-long time friends. They are (stricty in alphabetical order): Alessandro “Pari” Parimbelli, Ambrogio “Bobo” Usuelli, Andrea “Maken” Machini, Antonio “the Awesome” Carzaniga, Dario “Pitone” Galbiati, Federico “Fede” Clonfero, Flavio “Spadone” Spada, Gianpaolo “the Red One” Cugola, Giovanni “Negroni” Denaro, Giovanni “Muscle Man” Vigna, Lorenzo “the Diver” Riva, Matteo “Prada” Pradella, Mattia “il Monga” Monga, Niels “l’e´ semper chi” Kierkegaard, Pierluigi “San Peter” Sanpietro, Sergio “Que viva Mex- ico” Silva.