The document discusses verification and validation techniques for robotic assistants. It describes three approaches used in the Trustworthy Robotic Assistants Project: formal verification using tools like model checkers, simulation-based testing to generate scenarios, and end-user validation through experiments. Two use cases are also discussed: a personal robot assistant in a simulated domestic home and a cooperative manufacturing robot.
Finding Bugs, Fixing Bugs, Preventing Bugs ā Exploiting Automated Tests to In...University of Antwerp
Ā
With the rise of agile development, software teams all over the world embrace faster release cycles as *the* way to incorporate customer feedback into product development processes. Yet, faster release cycles imply rethinking the traditional notion of software quality: agile teams must balance reliability (minimize known defects) against agility (maximize ease of change). This talk will explore the state-of-the-art in software test automation and the opportunities this may present for maintaining this balance. We will address questions like: Will our test suite detect critical defects early? If not, how can we improve our test suite? Where should we fix a defect?
(Keynote for the SHIFT 2020 and IWSF 2020 Workshops, October 2020)
Formal Verification of Developer Tests: a Research Agenda Inspired by Mutatio...University of Antwerp
Ā
With the current emphasis on DevOps, automated software tests become a necessary ingredient for continuously evolving, high-quality software systems. This implies that the test code takes a significant portion of the complete code base ā test to code ratios ranging from 3:1 to 2:1 are quite common.
We argue that "testware'" provides interesting opportunities for formal verification, especially because the system under test may serve as an oracle to focus the analysis. As an example we describe five common problems (mainly from the subfield of mutation testing) and how formal verification may contribute.
We deduce a research agenda as an open invitation for fellow researchers to investigate the peculiarities of formally verifying testware.
With the rise of agile development and the adoption of continuous integration, the software industry has seen an increasing interest in test automation. Many organizations invest in test automation but fail to reap the expected benefits, most likely due to a lack of test-automation maturity. In this talk, we present the results of a test automation maturity survey collecting responses of 151 practitioners coming from 101 organizations in 25 countries. We make observations regarding the state of the practice and provide a benchmark for assessing the maturity of an agile team. The benchmark resulted in a self-assessment tool for practitioners to be released under an open source license. An alfa version is presented herein. The research underpinning the survey has been conducted through the TESTOMAT project, a European project with 34 partners coming from 6 different countries.
(Presentation delivered at the Test Automation Days and the Testnet Autumn Event; October 2020)
Reproducible Crashes: Fuzzing Pharo by Mutating the Test MethodsUniversity of Antwerp
Ā
Fuzzing (or Fuzz Testing) is a technique to verify the robustness of a program-under-test. Valid input is replaced by random values with the goal to force the program-under-test into unresponsive states. In this position paper, we propose a white box Fuzzing approach by transforming (mutating) existing test methods. We adopt the mechanisms used for test amplification to generate crash inducing tests, which developers can reproduce later. We provide anecdotal evidence that our approach towards Fuzzing reveals crashing issues in the Pharo environment.
Finding Bugs, Fixing Bugs, Preventing Bugs ā Exploiting Automated Tests to In...University of Antwerp
Ā
With the rise of agile development, software teams all over the world embrace faster release cycles as *the* way to incorporate customer feedback into product development processes. Yet, faster release cycles imply rethinking the traditional notion of software quality: agile teams must balance reliability (minimize known defects) against agility (maximize ease of change). This talk will explore the state-of-the-art in software test automation and the opportunities this may present for maintaining this balance. We will address questions like: Will our test suite detect critical defects early? If not, how can we improve our test suite? Where should we fix a defect?
(Keynote for the SHIFT 2020 and IWSF 2020 Workshops, October 2020)
Formal Verification of Developer Tests: a Research Agenda Inspired by Mutatio...University of Antwerp
Ā
With the current emphasis on DevOps, automated software tests become a necessary ingredient for continuously evolving, high-quality software systems. This implies that the test code takes a significant portion of the complete code base ā test to code ratios ranging from 3:1 to 2:1 are quite common.
We argue that "testware'" provides interesting opportunities for formal verification, especially because the system under test may serve as an oracle to focus the analysis. As an example we describe five common problems (mainly from the subfield of mutation testing) and how formal verification may contribute.
We deduce a research agenda as an open invitation for fellow researchers to investigate the peculiarities of formally verifying testware.
With the rise of agile development and the adoption of continuous integration, the software industry has seen an increasing interest in test automation. Many organizations invest in test automation but fail to reap the expected benefits, most likely due to a lack of test-automation maturity. In this talk, we present the results of a test automation maturity survey collecting responses of 151 practitioners coming from 101 organizations in 25 countries. We make observations regarding the state of the practice and provide a benchmark for assessing the maturity of an agile team. The benchmark resulted in a self-assessment tool for practitioners to be released under an open source license. An alfa version is presented herein. The research underpinning the survey has been conducted through the TESTOMAT project, a European project with 34 partners coming from 6 different countries.
(Presentation delivered at the Test Automation Days and the Testnet Autumn Event; October 2020)
Reproducible Crashes: Fuzzing Pharo by Mutating the Test MethodsUniversity of Antwerp
Ā
Fuzzing (or Fuzz Testing) is a technique to verify the robustness of a program-under-test. Valid input is replaced by random values with the goal to force the program-under-test into unresponsive states. In this position paper, we propose a white box Fuzzing approach by transforming (mutating) existing test methods. We adopt the mechanisms used for test amplification to generate crash inducing tests, which developers can reproduce later. We provide anecdotal evidence that our approach towards Fuzzing reveals crashing issues in the Pharo environment.
2010-03-31 - VU Amsterdam - Experiences testing safety critical systemsJaap van Ekris
Ā
Presentation about the steps required for Verifying and Vlaidating safety critical systems, as well as the test approach used. Contains examples of real-life IEC 61508 SIL 4 systems.
Introduction of testing and verification of vlsi designUsha Mehta
Ā
This slides are introductory slides for the course testing and verification of VLSI Design which cover the basics of Why, Where, When and How of VLSI design testing
2021 08-28, QONFEST 2021 - Reliability cenetered maintenance for sleeping giantsJaap van Ekris
Ā
Many safety systems are designed to be never used: they are safety nets, waiting to avert the disaster that hopefully never will happen. For example the Dutch Storm surge barriers, dormant giants waiting to be used, but only really active every year or even once every ten years. How do you know that such a system is there when you need it. Is the giant safely asleep, or did he die without us noticing it? How do you design and optimise its maintenance, where its biggest problem is dormant failure? In this talk I adress the approach used for these systems.
Reverse engineering is not just about uncovering the hidden behaviour of a given technology, system, program or device. It's actually an art and a mindset. Reversing is used by some government agencies, secret services, antivirus software companies, hackers and students. It can be used for many purposes: cracking/bypassing software, botnet analysis, finding 0day exploits, interpreting unknown protocols, understanding malware or finding bugs in apps.
2010-03-31 - VU Amsterdam - Experiences testing safety critical systemsJaap van Ekris
Ā
Presentation about the steps required for Verifying and Vlaidating safety critical systems, as well as the test approach used. Contains examples of real-life IEC 61508 SIL 4 systems.
Introduction of testing and verification of vlsi designUsha Mehta
Ā
This slides are introductory slides for the course testing and verification of VLSI Design which cover the basics of Why, Where, When and How of VLSI design testing
2021 08-28, QONFEST 2021 - Reliability cenetered maintenance for sleeping giantsJaap van Ekris
Ā
Many safety systems are designed to be never used: they are safety nets, waiting to avert the disaster that hopefully never will happen. For example the Dutch Storm surge barriers, dormant giants waiting to be used, but only really active every year or even once every ten years. How do you know that such a system is there when you need it. Is the giant safely asleep, or did he die without us noticing it? How do you design and optimise its maintenance, where its biggest problem is dormant failure? In this talk I adress the approach used for these systems.
Reverse engineering is not just about uncovering the hidden behaviour of a given technology, system, program or device. It's actually an art and a mindset. Reversing is used by some government agencies, secret services, antivirus software companies, hackers and students. It can be used for many purposes: cracking/bypassing software, botnet analysis, finding 0day exploits, interpreting unknown protocols, understanding malware or finding bugs in apps.
Practical Application of Agile Techniques in Developing Safety Related SystemsAdaCore
Ā
David Nicoll will present some of his experiences of applying Agile techniques to improve the effective development and delivery of software projects including their use in developing safety related systems within a regulatory frameworks. David will also show how the safety engineering process and generation of evidence are not adversely impacted by this approach.
How should we build that? Evolving a development environment that's suitable ...AdaCore
Ā
We are building ever more complex systems, and demanding of them ever higher standards of reliability, functionality, and safety. The development environment for the successful project you just delivered almost certainly needs enhancing for your next project. Maybe your team needs to use new tools, new methodologies, new architectural patterns, new process, or just a new language. You can analyse past projects, and research other people's work, but how do you choose what enhancements to make? And how do you deploy new process or tooling in an industrial context where time-to-market, margin, and success are everything? This talk will look at the key drivers behind the successful adoption of any new process or tool - from a small incremental update to a major shift in development philosophy. Along the way we will look at some real-world successes, and face up to a few challenges.
Mixed Criticality Systems and Many-Core PlatformsAdaCore
Ā
An increasingly important trend in the design of real-time and embedded systems is the integration of components with different levels of criticality onto a common hardware platform. At the same time, these platforms are migrating from single cores to multi-cores and, in the future, manycore architectures. Criticality is a designation of the level of assurance against failure needed for a system component.
A mixed criticality system (MCS) is one that has two or more distinct levels (for example safety critical, mission critical and non-critical). Perhaps up to five levels may be identified (see, for example, the IEC 61508, DO-178B, DO-254 and ISO 26262 standards). In this talk some of the techniques being developed for MCS will be outlined, as will schemes by which the different assuance methods for each criticality level can be exploited to reduce resource usage.
Mind your language(s), A Discussion about Languages and SecurityAdaCore
Ā
Following several studies conducted by the French Network and Information Security Agency (ANSSI), this presentation discusses the question of the intrinsic security characteristics of programming languages. Through illustrations and discussions, it advocates for a different vision of well-known mechanisms and is intended to provide some food for thoughts regarding languages and development tools.
"An Insight into MISRA-C 2012" provides an understanding of what MISRA-C 2012 provides to critical systems software development with the C programming language. It begins with a brief review of the origins of C and why some consider it to be a poor choice for critical systems. The reasons why others consider it the only viable choice to make are then touched upon. Making C safer then becomes the subject of the talk and this forms the backdrop to the purpose of the MISRA C guidelines. Finally, we explore what it takes to claim MISRA C 2012 compliance.
The talk should be of interest to both C and non-C developers with an interest in software coding standards. The talk does not cover the technicalities of any of the MISRA C guidelines. Consequentially, no knowledge of the C programming language is required beyond a general programming background.
Dave Banham, Software System Specialist, Rolls-Royce
Writing large error-free software is extremely challenging or even infeasible. In order to be able to assure critical security properties it is therefore necessary to decompose the system into small security critical subjects whose correctness has to be shown and other large uncritical parts which cannot endanger security. A separation kernel can be used to assure the independent execution of multiple subjects and the enforcement of pre-defined communication channels between subjects. The correctness of the separation kernel is therefore essential for overall security.
In this talk we describe the design and implementation of the Muen separation kernel which uses the SPARK language to enable light-weight formal methods for assurance. Besides a discussion of x86 virtualization, system integration, as well as present and planned verification we demonstrate how Muen enables the construction of high security systems on x86 hardware.
Samples pages of a title that I performed the layout on from a series published by ReferencePoint Press.
Contact me through my LinkedIn profile at https://www.linkedin.com/in/joeparenteau1
Machine Vision On Embedded Platform -ReportOmkar Rane
Ā
Implementation of machine learning algorithms like color based segmentation on embedded platform.
This Project is useful for implementing Robotic Vision, process control and quality control in industry.
A Survey of functional verification techniquesIJSRD
Ā
In this paper, we present a survey of various techniques used in functional verification of industry hardware designs. Although the use of formal verification techniques has been increasing over time, there is still a need for an immediate practical solution resulting in an increased interest in hybrid verification techniques. Hybrid techniques combine formal and informal (traditional simulation based) techniques to take the advantage of both the worlds. A typical hybrid technique aims to address the verification bottleneck by enhancing the state space coverage.
Re-Evaluating the Value and Market Positioning of Industrial CobotsLizzie Uhl
Ā
As one of the largest integrators in the nation, JR Automation sees nearly every type of request for automation. Because of that, we have gained a unique perspective on what cobot features end consumers are actually asking for and are willing to spend money on.
This presentation focuses on where cobots are being applied, where they can bring the most value to a business, and how their value can be fully realized.
Industrial robotics is entering a new era of adaptability and thereās a lot to keep up with for all engineers involved in their use, their programming, or their design. This webinar will address several critical areas that are undergoing rapid transformation, including sensing and perception, micro-robotics, and soft robotics.
MODELING (mechanical) AND ANALYSIS OF ROBO-ARM FOR PICK AND PLACE OPERATION I...ijsrd.com
Ā
Robo- arm is assembly of number of joints which can work in 180 degree direction that allows the object to 'move' in its require direction, and is commonly used in mechanical industry where pick and place operation are carried out .It consists of a pair of hinges located close together, oriented at maximum 90ĆāĆĀ° to each other, connected by a pin joint .Now, this project is based from ceramic industry in which the robo-arm perform its operation for pick and place activity very quickly. Here, I design the mechanical structure of robo-arm. Robo-arm can work at which places where, human can't work continuously in ceramic industry. For example at Furnace division .Robo-arm has its own end effectors. with the help of it, rob-arm can pick the object easily and safely. Basic design concept is taken from ceramic industry at the furnace division where, the working temperature is more than ambient temperature .With the help robo -arm we can save the time and cost, as compare to crane operated loading system and manual belt conveyor system, because robo-arm can place the component at particular place of the part storage area.
RCA OCORA: Safe Computing Platform using open standardsAdaCore
Ā
The railway sector is facing a major transition as it moves towards more fully automated systems on both the train and infrastructure side. This in turn, requires the development of appropriate, future-proof connectivity and IT platforms.
The Reference Control Command and Signalling Architecture (RCA) and Open Control Command and Signalling Onboard Reference Architecture (OCORA) have developed a functional architecture for future trackside and onboard functions. The RCA OCORA open Control Command Signalling (CCS) on-board reference architecture introduces a standardized separation of safety-relevant and non-safety-relevant railway applications and the underlying IT platforms. This allows rail operators to decouple the very distinct life cycles of the domains and aggregate multiple railway applications on common IT platforms.
Based on a Safe Computing Platform (SCP), the architecture accommodates a Platform Independent Application Programming Interface (PI API) between safety-relevant railway applications and IT platforms. This approach supports the portability of railway applications among IT platform realisations from different vendors.
Two of its authors will discuss the RCA OCORA architecture with emphasis on its safe computing framework. The talk will review the required operating system standards and the discuss the newly-released DDS Reference Implementation for Safe Computing Platform Messaging. While designed for rail, this architecture will have elements of interest for other industries.
Rust and the coming age of high integrity languagesAdaCore
Ā
Rust is undeniably successful. In just over 7 year, it moved from a newly released language to one that is considered as a language for high integrity systems. This success did not happen in isolation - Rusts success is deeply rooted in a number of contributing environmental factors.
In this talk, Iād like to make the case why Rust success is due to a general ground shift in software development. What we are seeing is a resurging interest in software practices that were usually part of safety-critical environments being applied to non-safety related, mission-critical environments. On the other side, we are seeing the worlds of safety and security merging.
Iād like to take a step back and talk about coming opportunities, changes and chances not only for Rust, but also for other languages and products.
SPARKNaCl: A verified, fast cryptographic libraryAdaCore
Ā
SPARKNaCl https://github.com/rod-chapman/SPARKNaCl is a new, freely-available, verified and fast reference implementation of the NaCl cryptographic API, based on the TweetNaCl distribution. It has a fully automated, complete and sound proof of type-safety and several key correctness properties. In addition, the code is surprisingly fast - out-performing TweetNaCl's C implementation on an Ed25519 Sign operation by a factor of 3 at all optimisation levels on a 32-bit RISC-V bare-metal machine. This talk will concentrate on how "Proof Driven Optimisation" can result in code that is both correct and fast.
Developing Future High Integrity Processing SolutionsAdaCore
Ā
Rolls-Royce has been developing high integrity digital processing solutions for its safety critical aerospace engine controllers since the 1980s. By the turn of the century, the electronics industry experienced an inflection point. This resulted in a shift to a consumer driven market and a much-reduced focus on the harsh environment electronics and the extended life cycles required by the aerospace industry. As a result, Rolls-Royce took the decision to design its own microprocessor, and for the last 25 years, has been successfully developing harsh environment safety critical processing solutions for all its aerospace engines.
Alongside the ever-increasing performance expectations, the past few years have seen cyber-security become a major driver in new processor developments. This presents new and interesting development challenges that will need to be addressed.
Taming event-driven software via formal verificationAdaCore
Ā
Event-driven software can be found everywhere, from low-level drivers, to software that controls and coordinates complex subcomponents, and even in GUIs. Typically, event-driven software is characterised as consisting of a number of stateful components that communicate by sending messages to each other. Event-driven software is notoriously difficult to test. There are often many different sequences of events, and because the exact order of the events will affect the state of the system, it can be easy for bugs to lurk in obscure un-tested sequences of events. Even worse, reproducing these bugs can be difficult due to the need to reproduce the exact sequence of events that led to the issue.
Formal verification is one method of solving this: rather than writing tests to check each of the different possible sequences of events, automated formal verification could be used to verify that the software is correct no matter what sequence of events is observed. In this talk, we will look at what capabilities are required to ensure that this will be successful, including what it means for event-driven software to be correct, and how to ensure that the verification can scale to industrial-sized software projects.
Pushing the Boundary of Mostly Automatic Program ProofAdaCore
Ā
With the large-scale verification of complex programs like compilers and microkernels, program proof has realised the grand challenge of creating a āverifying compilerā proposed by Sir Tony Hoare in 2003. Still, the effort and expertise required for developing the program and its proof to feed to the āverifying compilerā will exceed the V&V budget of most projects. Another approach gaining traction is to automate the proof as much as possible. More specifically, by tailoring the proof tool to the strengths of a target programming language, leveraging an array of automatic provers, and limiting the ambition of proof to those properties for which proof can be mostly automated. This is the approach we are following in SPARK. In this talk, we will survey what properties can be āmostlyā proved automatically, and what this means in terms of effort and expertise.
RCA OCORA: Safe Computing Platform using open standardsAdaCore
Ā
The railway sector is facing a major transition as it moves towards more fully automated systems on both the train and infrastructure side. This in turn, requires the development of appropriate, future-proof connectivity and IT platforms.
The Reference Control Command and Signalling Architecture (RCA) and Open Control Command and Signalling Onboard Reference Architecture (OCORA) have developed a functional architecture for future trackside and onboard functions. The RCA OCORA open Control Command Signalling (CCS) on-board reference architecture introduces a standardized separation of safety-relevant and non-safety-relevant railway applications and the underlying IT platforms. This allows rail operators to decouple the very distinct life cycles of the domains and aggregate multiple railway applications on common IT platforms.
Based on a Safe Computing Platform (SCP), the architecture accommodates a Platform Independent Application Programming Interface (PI API) between safety-relevant railway applications and IT platforms. This approach supports the portability of railway applications among IT platform realisations from different vendors.
Two of its authors will discuss the RCA OCORA architecture with emphasis on its safe computing framework. The talk will review the required operating system standards and the discuss the newly-released DDS Reference Implementation for Safe Computing Platform Messaging. While designed for rail, this architecture will have elements of interest for other industries.
Product Lines and Ecosystems: from customization to configurationAdaCore
Ā
Digitalization is concerned with a fundamental shift in value delivery to customers from transactional to continuous. For R&D this requires adopting processes such as DevOps and continuous deployment. Systems engineering companies using platforms need to adjust their ways of working and be cognisant of the role of the ecosystem surrounding them to capitalize on this transformation. The keynote talk will discuss these developments and provide industrial examples from Software Center, a collaboration between 17 large, international companies and five universities with the intent of accelerating the digital transformation of the European software intensive industry.
Pushing the limits of ePRTC: 100ns holdover for 100 daysAdtran
Ā
At WSTS 2024, Alon Stern explored the topic of parametric holdover and explained how recent research findings can be implemented in real-world PNT networks to achieve 100 nanoseconds of accuracy for up to 100 days.
Essentials of Automations: The Art of Triggers and Actions in FMESafe Software
Ā
In this second installment of our Essentials of Automations webinar series, weāll explore the landscape of triggers and actions, guiding you through the nuances of authoring and adapting workspaces for seamless automations. Gain an understanding of the full spectrum of triggers and actions available in FME, empowering you to enhance your workspaces for efficient automation.
Weāll kick things off by showcasing the most commonly used event-based triggers, introducing you to various automation workflows like manual triggers, schedules, directory watchers, and more. Plus, see how these elements play out in real scenarios.
Whether youāre tweaking your current setup or building from the ground up, this session will arm you with the tools and insights needed to transform your FME usage into a powerhouse of productivity. Join us to discover effective strategies that simplify complex processes, enhancing your productivity and transforming your data management practices with FME. Letās turn complexity into clarity and make your workspaces work wonders!
GDG Cloud Southlake #33: Boule & Rebala: Effective AppSec in SDLC using Deplo...James Anderson
Ā
Effective Application Security in Software Delivery lifecycle using Deployment Firewall and DBOM
The modern software delivery process (or the CI/CD process) includes many tools, distributed teams, open-source code, and cloud platforms. Constant focus on speed to release software to market, along with the traditional slow and manual security checks has caused gaps in continuous security as an important piece in the software supply chain. Today organizations feel more susceptible to external and internal cyber threats due to the vast attack surface in their applications supply chain and the lack of end-to-end governance and risk management.
The software team must secure its software delivery process to avoid vulnerability and security breaches. This needs to be achieved with existing tool chains and without extensive rework of the delivery processes. This talk will present strategies and techniques for providing visibility into the true risk of the existing vulnerabilities, preventing the introduction of security issues in the software, resolving vulnerabilities in production environments quickly, and capturing the deployment bill of materials (DBOM).
Speakers:
Bob Boule
Robert Boule is a technology enthusiast with PASSION for technology and making things work along with a knack for helping others understand how things work. He comes with around 20 years of solution engineering experience in application security, software continuous delivery, and SaaS platforms. He is known for his dynamic presentations in CI/CD and application security integrated in software delivery lifecycle.
Gopinath Rebala
Gopinath Rebala is the CTO of OpsMx, where he has overall responsibility for the machine learning and data processing architectures for Secure Software Delivery. Gopi also has a strong connection with our customers, leading design and architecture for strategic implementations. Gopi is a frequent speaker and well-known leader in continuous delivery and integrating security into software delivery.
Smart TV Buyer Insights Survey 2024 by 91mobiles.pdf91mobiles
Ā
91mobiles recently conducted a Smart TV Buyer Insights Survey in which we asked over 3,000 respondents about the TV they own, aspects they look at on a new TV, and their TV buying preferences.
Enhancing Performance with Globus and the Science DMZGlobus
Ā
ESnet has led the way in helping national facilitiesāand many other institutions in the research communityāconfigure Science DMZs and troubleshoot network issues to maximize data transfer performance. In this talk we will present a summary of approaches and tips for getting the most out of your network infrastructure using Globus Connect Server.
GraphRAG is All You need? LLM & Knowledge GraphGuy Korland
Ā
Guy Korland, CEO and Co-founder of FalkorDB, will review two articles on the integration of language models with knowledge graphs.
1. Unifying Large Language Models and Knowledge Graphs: A Roadmap.
https://arxiv.org/abs/2306.08302
2. Microsoft Research's GraphRAG paper and a review paper on various uses of knowledge graphs:
https://www.microsoft.com/en-us/research/blog/graphrag-unlocking-llm-discovery-on-narrative-private-data/
The Metaverse and AI: how can decision-makers harness the Metaverse for their...Jen Stirrup
Ā
The Metaverse is popularized in science fiction, and now it is becoming closer to being a part of our daily lives through the use of social media and shopping companies. How can businesses survive in a world where Artificial Intelligence is becoming the present as well as the future of technology, and how does the Metaverse fit into business strategy when futurist ideas are developing into reality at accelerated rates? How do we do this when our data isn't up to scratch? How can we move towards success with our data so we are set up for the Metaverse when it arrives?
How can you help your company evolve, adapt, and succeed using Artificial Intelligence and the Metaverse to stay ahead of the competition? What are the potential issues, complications, and benefits that these technologies could bring to us and our organizations? In this session, Jen Stirrup will explain how to start thinking about these technologies as an organisation.
Securing your Kubernetes cluster_ a step-by-step guide to success !KatiaHIMEUR1
Ā
Today, after several years of existence, an extremely active community and an ultra-dynamic ecosystem, Kubernetes has established itself as the de facto standard in container orchestration. Thanks to a wide range of managed services, it has never been so easy to set up a ready-to-use Kubernetes cluster.
However, this ease of use means that the subject of security in Kubernetes is often left for later, or even neglected. This exposes companies to significant risks.
In this talk, I'll show you step-by-step how to secure your Kubernetes cluster for greater peace of mind and reliability.
Epistemic Interaction - tuning interfaces to provide information for AI supportAlan Dix
Ā
Paper presented at SYNERGY workshop at AVI 2024, Genoa, Italy. 3rd June 2024
https://alandix.com/academic/papers/synergy2024-epistemic/
As machine learning integrates deeper into human-computer interactions, the concept of epistemic interaction emerges, aiming to refine these interactions to enhance system adaptability. This approach encourages minor, intentional adjustments in user behaviour to enrich the data available for system learning. This paper introduces epistemic interaction within the context of human-system communication, illustrating how deliberate interaction design can improve system understanding and adaptation. Through concrete examples, we demonstrate the potential of epistemic interaction to significantly advance human-computer interaction by leveraging intuitive human communication strategies to inform system design and functionality, offering a novel pathway for enriching user-system engagements.
Observability Concepts EVERY Developer Should Know -- DeveloperWeek Europe.pdfPaige Cruz
Ā
Monitoring and observability arenāt traditionally found in software curriculums and many of us cobble this knowledge together from whatever vendor or ecosystem we were first introduced to and whatever is a part of your current companyās observability stack.
While the dev and ops silo continues to crumbleā¦.many organizations still relegate monitoring & observability as the purview of ops, infra and SRE teams. This is a mistake - achieving a highly observable system requires collaboration up and down the stack.
I, a former op, would like to extend an invitation to all application developers to join the observability party will share these foundational concepts to build on:
A tale of scale & speed: How the US Navy is enabling software delivery from l...sonjaschweigert1
Ā
Rapid and secure feature delivery is a goal across every application team and every branch of the DoD. The Navyās DevSecOps platform, Party Barge, has achieved:
- Reduction in onboarding time from 5 weeks to 1 day
- Improved developer experience and productivity through actionable findings and reduction of false positives
- Maintenance of superior security standards and inherent policy enforcement with Authorization to Operate (ATO)
Development teams can ship efficiently and ensure applications are cyber ready for Navy Authorizing Officials (AOs). In this webinar, Sigma Defense and Anchore will give attendees a look behind the scenes and demo secure pipeline automation and security artifacts that speed up application ATO and time to production.
We will cover:
- How to remove silos in DevSecOps
- How to build efficient development pipeline roles and component templates
- How to deliver security artifacts that matter for ATOās (SBOMs, vulnerability reports, and policy evidence)
- How to streamline operations with automated policy checks on container images
LF Energy Webinar: Electrical Grid Modelling and Simulation Through PowSyBl -...DanBrown980551
Ā
Do you want to learn how to model and simulate an electrical network from scratch in under an hour?
Then welcome to this PowSyBl workshop, hosted by Rte, the French Transmission System Operator (TSO)!
During the webinar, you will discover the PowSyBl ecosystem as well as handle and study an electrical network through an interactive Python notebook.
PowSyBl is an open source project hosted by LF Energy, which offers a comprehensive set of features for electrical grid modelling and simulation. Among other advanced features, PowSyBl provides:
- A fully editable and extendable library for grid component modelling;
- Visualization tools to display your network;
- Grid simulation tools, such as power flows, security analyses (with or without remedial actions) and sensitivity analyses;
The framework is mostly written in Java, with a Python binding so that Python developers can access PowSyBl functionalities as well.
What you will learn during the webinar:
- For beginners: discover PowSyBl's functionalities through a quick general presentation and the notebook, without needing any expert coding skills;
- For advanced developers: master the skills to efficiently apply PowSyBl functionalities to your real-world scenarios.
State of ICS and IoT Cyber Threat Landscape Report 2024 previewPrayukth K V
Ā
The IoT and OT threat landscape report has been prepared by the Threat Research Team at Sectrio using data from Sectrio, cyber threat intelligence farming facilities spread across over 85 cities around the world. In addition, Sectrio also runs AI-based advanced threat and payload engagement facilities that serve as sinks to attract and engage sophisticated threat actors, and newer malware including new variants and latent threats that are at an earlier stage of development.
The latest edition of the OT/ICS and IoT security Threat Landscape Report 2024 also covers:
State of global ICS asset and network exposure
Sectoral targets and attacks as well as the cost of ransom
Global APT activity, AI usage, actor and tactic profiles, and implications
Rise in volumes of AI-powered cyberattacks
Major cyber events in 2024
Malware and malicious payload trends
Cyberattack types and targets
Vulnerability exploit attempts on CVEs
Attacks on counties ā USA
Expansion of bot farms ā how, where, and why
In-depth analysis of the cyber threat landscape across North America, South America, Europe, APAC, and the Middle East
Why are attacks on smart factories rising?
Cyber risk predictions
Axis of attacks ā Europe
Systemic attacks in the Middle East
Download the full report from here:
https://sectrio.com/resources/ot-threat-landscape-reports/sectrio-releases-ot-ics-and-iot-security-threat-landscape-report-2024/
State of ICS and IoT Cyber Threat Landscape Report 2024 preview
Ā
Verification and Validation of Robotic Assistants
1. Introduction Techniques and Approach The Domestic Scenario The Manufacturing Scenario Conclusions
Veriļ¬cation and Validation of Robotic Assistants
Clare Dixon
Department of Computer Science
University of Liverpool
1 University of Liverpool (UoL)
2 University of Hertfordshire (UoH)
3 Bristol Robotics Lab (BRL)
www.robosafe.org
Farshid Amirabdollahian2
Kerstin Dautenhahn2 Anthony Pipe3
Kerstin Eder3 Maha Salem2
Michael Fisher1 Joe Saunders2
Dejanira Araiza Illan3 Matt Webster1
Kheng Lee Koay2 David Western3
Clare Dixon Veriļ¬cation and Validation Robotic Assistants 1 / 23
2. Introduction Techniques and Approach The Domestic Scenario The Manufacturing Scenario Conclusions
Robotic Assistants
Robotic assistants are being developed to
help, or work closely with humans in
industrial, domestic and health care
environments (e.g. RI-MAN, Pearl,
Wakamaru, . . . )
The robots will need to be able to act
autonomously and make decisions to
choose between a range of activities.
In addition they will need to operate close
to, or in collaboration with humans.
How do we make sure they are trustworthy,
safe, reliable and do what they are
supposed to?
Wakamaru image by Nesnad (Own work) [CC BY-SA 3.0 (http://creativecommons.org/licenses/by-sa/3.0) or GFDL
(http://www.gnu.org/copyleft/fdl.html)], via Wikimedia Commons
Clare Dixon Veriļ¬cation and Validation Robotic Assistants 2 / 23
3. Introduction Techniques and Approach The Domestic Scenario The Manufacturing Scenario Conclusions
What is Trustworthiness and Safety?
Safety involves showing that the robot does nothing that
(unnecessarily) endangers the person.
There are ISO safety requirements and guidelines for
industrial robots (ISO 10218, 2011), personal care robots
(ISO 13482, 2014), and for collaborative robots (ISO
15066, 2016).
Trustworthiness involves social issues beyond pure safety.
It is not just a question of whether the robots are safe but
whether they are perceived to be safe, useful and reliable.
There are also legal (and ethical) issues such as what
happens when
the robot spills a hot drink on someone;
the robot doesnāt remind the person to take their medicine;
the robot doesnāt go to the kitchen when told?
Clare Dixon Veriļ¬cation and Validation Robotic Assistants 3 / 23
4. Introduction Techniques and Approach The Domestic Scenario The Manufacturing Scenario Conclusions
Robots in the Workplace and at Home
Currently many robots used in industry or domestic use operate
in limited physical space or have limited functionality. This helps
assure their safety.
Robotsā industrial environments are limited so they can
only move in a ļ¬xed area and have limited interactions with
humans e.g. welding or paint spraying robots.
Small or limited capability domestic robots, e.g., vacuum
cleaning robots, robot lawn mowers, pool cleaning robots
etc
Clare Dixon Veriļ¬cation and Validation Robotic Assistants 4 / 23
5. Introduction Techniques and Approach The Domestic Scenario The Manufacturing Scenario Conclusions
Trustworthy Robotic Assistants Project
The EPSRC funded Trustworthy Robotic Assistants Project
develops three different approaches to veriļ¬cation and
validation of robotic assistants.
Each approach is aimed at increasing trust in robotic assistants.
Formal Veriļ¬cation (Liverpool)
Simulation-based Testing (Bristol Robotics Laboratory)
End-user Validation (Hertfordshire)
Clare Dixon Veriļ¬cation and Validation Robotic Assistants 5 / 23
6. Introduction Techniques and Approach The Domestic Scenario The Manufacturing Scenario Conclusions
Robotic Assistants
We consider two use cases, domestic
and manufacturing.
A personal robot assistant (the Care-
O-bot R
,) located in a domestic house
in the University of Hertfordshire.
A co-operative manufacturing task
with BERT a robot at Bristol Robotics
Lab.
8 Journal Title XX(X)
ā¢ System model inaccuracies. All the veriļ¬cation
techniques use models of the real-world. The models
might have been constructed erroneously, or may be
inconsistent with the real world, or relative to one
another.
ā¢ Requirement model inaccuracies. In our approach,
the real-world requirements of the system are con-
verted into textual requirements, assertions and prop-
erties for veriļ¬cation. These requirements models
may not have been correctly formulated.
ā¢ Tool inaccuracies. It is possible that numerical
approximations affect the veriļ¬cation results. In
addition, third party tools can contain bugs that are
unknown to us.
We could now proceed to perform āExperiments.ā As
before, we may ļ¬nd a problem with the textual require-
ments or the physical system during experimentation. At
Figure 2. BERT 2 engaged in the handover task.
robot. BERT 2 then picks up a nearby object, and holdsClare Dixon Veriļ¬cation and Validation Robotic Assistants 6 / 23
7. Introduction Techniques and Approach The Domestic Scenario The Manufacturing Scenario Conclusions
Formal Veriļ¬cation
A mathematical analysis of all behaviours using logics, and
tools such as theorem provers or model checkers.
We focus on temporal veriļ¬cation using automatic tools
and techniques that do not require user interaction.
Model checking is a fully automatic, algorithmic technique
for verifying the temporal properties of systems.
Input to the model checker is a model of the system and a
property to be checked on that model.
Output is that the property is satisļ¬ed or a counter
example is given.
Model Checker
Property holds
or
counter example
Property eg
"always p"
Clare Dixon Veriļ¬cation and Validation Robotic Assistants 7 / 23
8. Introduction Techniques and Approach The Domestic Scenario The Manufacturing Scenario Conclusions
Robot Architectures and Veriļ¬cation
We assume an architecture where there is a separation
between the high level decision making layer and the low level
control layer.
etc
Control System
Sense and act
High level choices
Rational Agent
Low level control
Decision making
Avoidance
Reactive
Goal selection
Plan selection
Prediction
etc
We aim to represent and verify the decision making layer and
we donāt deal with low level control such as movement etc.
Clare Dixon Veriļ¬cation and Validation Robotic Assistants 8 / 23
9. Introduction Techniques and Approach The Domestic Scenario The Manufacturing Scenario Conclusions
Simulation Based Testing
This is an exhaustive testing methodology widely used in
the design of micro-electronic and avionics systems.
These appeal to Monte-Carlo techniques and dynamic test
reļ¬nement in order to cover a wide range or practical
situations.
Tools are used to automate the testing and analyse the
coverage of the tests.
over Scenario
Clare Dixon Veriļ¬cation and Validation Robotic Assistants 9 / 23
10. Introduction Techniques and Approach The Domestic Scenario The Manufacturing Scenario Conclusions
End User Validation
This approach involves experiments and user evaluations
in practical robotic scenarios.
Scenarios relating to robot human interaction are
developed to test some hypothesis and experiments with
users carried out.
This helps establish whether the human participants
indeed view the robotic assistants as safe and trustworthy.
Clare Dixon Veriļ¬cation and Validation Robotic Assistants 10 / 23
11. Introduction Techniques and Approach The Domestic Scenario The Manufacturing Scenario Conclusions
Overall Approach
Clare Dixon Veriļ¬cation and Validation Robotic Assistants 11 / 23
12. Introduction Techniques and Approach The Domestic Scenario The Manufacturing Scenario Conclusions
A Domestic Robot Assistant
Here we apply model checking to the
high level behaviours controlling the
(commercially available) Care-O-bot R
,
manufactured by Fraunhofer IPA.
It is based on the concept of a ārobot
butlerā which has been developed as a
mobile robotic assistant to support
people in domestic environments.
It has a manipulator arm, an articulated
torso, stereo sensors serving as āeyesā,
LED lights, a graphical user interface,
and a moveable tray.
The robotās sensors monitor its current location, the state
of the arm, torso, eyes and tray.
Its software is based on the Robot Operating System.
Clare Dixon Veriļ¬cation and Validation Robotic Assistants 12 / 23
13. Introduction Techniques and Approach The Domestic Scenario The Manufacturing Scenario Conclusions
Care-O-bot and Robot House
This is deployed in a domestic-type house (the robot
house) at the University of Hertfordshire.
The robot house is equipped with sensors which provide
information on the state of the house and its occupants,
such as whether the fridge door is open and whether
someone is seated on the sofa.
Low-level robot actions such as movement, speech, light
display, etc., are controlled by groups of high-level rules
that together deļ¬ne particular behaviours. 3
Fig. 2. A plan view of the ground ļ¬oor of the University of Hertfordshire Robot House. Numbered boxes show the locations of sensors.
models, and their formal veriļ¬cation, are described in
Section IV.
ā¢ Figs. 2 and 3 have been added to provide additional
information on the Robot House and the user activity
within it.
move_tray_and_wait(lowered_position)
set_light(white)
wait()
set(tray_is_raised,false)
set(tray_is_lowered,true)Clare Dixon Veriļ¬cation and Validation Robotic Assistants 13 / 23
14. Introduction Techniques and Approach The Domestic Scenario The Manufacturing Scenario Conclusions
Care-O-bot Decision Making: Behaviours
The Care-O-botās high-level decision making is determined
by a set of behaviours of the form precondition ā action
(each a sequence of rules).
Examples of high-level rules can take the form ālower trayā,
āmove to sofa area of the living roomā, āsay āThe fridge
door is openā ā, set a ļ¬ag, check a sensor etc.
Only one behaviour executes at once.
Each behaviour has a priority (integer between 0 and 90).
Higher priority behaviours are executed in preference to
lower priority behaviours.
Each behaviour is ļ¬agged as interruptible or not.
Once it has started executing, a behaviour will execute to
completion, if it is not interruptible.
Users can add new behaviours.
Clare Dixon Veriļ¬cation and Validation Robotic Assistants 14 / 23
15. Introduction Techniques and Approach The Domestic Scenario The Manufacturing Scenario Conclusions
The S1-alertFridgeDoor Behaviour
Behaviours (a set of high level rules) take the form:
Precondition-Rules -> Action-Rules
27 Fridge Freezer Is *ON* AND has been ON for more than 30 secs
31 ::514:: GOAL-fridgeUserAlerted is false
32 Turn light on ::0::Care-o-Bot 3.2 to yellow
34 move ::0::Care-o-Bot 3.2 to ::2:: Living Room and wait for
completion
35 Turn light on ::0::Care-o-Bot 3.2 to white and wait for
completion
36 ::0::Care-o-Bot 3.2 says āThe fridge door is open!ā and
wait for completion
37 SET ::506::GOAL-gotoCharger TO false
38 SET ::507::GOAL-gotoTable TO false
39 SET ::508::GOAL-gotoSofa TO false
40 ::0::Care-o-Bot 3.2 GUI, S1-Set-GoToKitchen, S1-Set-WaitHere
41 SET ::514::GOAL-fridgeUserAlerted TO true
Its priority is 60 and it is not interruptible.
Clare Dixon Veriļ¬cation and Validation Robotic Assistants 15 / 23
16. Introduction Techniques and Approach The Domestic Scenario The Manufacturing Scenario Conclusions
Models and Properties
We need to abstract away from some of the timing details
included in the database to obtain a model that is discrete,
ļ¬nite and not too large.
We developed a (by hand) model in the input language for
the model checker NuSMV and later developed a tool
(CRutoN) to automatically translate from behaviours to
NuSMV input.
We also need a set of properties of the system to check
over the model.
Ideally these would come from a speciļ¬cation or standards
documents about what is expected of the robot with
respect to functionality, safety etc.
Here we focus on issues relating to the scheduling of
behaviours, priorities and interruptions (which at least
provide a sanity check).
Clare Dixon Veriļ¬cation and Validation Robotic Assistants 16 / 23
17. Introduction Techniques and Approach The Domestic Scenario The Manufacturing Scenario Conclusions
Sample Properties and Model Checking Results
1 ((fridge_freezer_on ā§ Ā¬goal_fridge_user_alerted) ā
ā¦(location = livingroom ā§ ā¦say = fridge_door_open))
2 ((fridge_freezer_on ā§ Ā¬goal_fridge_user_alerted ā§
schedule = schedule_alert_fridge_door) ā
ā¦(location = livingroom ā§ ā¦say = fridge_door_open))
Property Output Time (sec)
1 FALSE 11.1
2 TRUE 12.3
The model had 130,593 reachable states.
We did ļ¬nd a small bug in the behaviours (a ļ¬ag was
wrongly set) but this was by inspection of the behaviours.
It would be better to try properties relating to the
requirements of the robot.
Clare Dixon Veriļ¬cation and Validation Robotic Assistants 17 / 23
18. Introduction Techniques and Approach The Domestic Scenario The Manufacturing Scenario Conclusions
Discussion
CRutoN allowed us to translate from different databases of
behaviours into input for a model checker, setting
parameters to control particular aspects of the translation.
CRutoN uses an intermediate representation so that input
to different model checkers can potentially be generated.
Understanding the semantics of the robot execution cycle
took a lot of close work and interaction with UoH.
The state explosion problem means we have to ļ¬nd a
balance between the level of detail/abstraction and
veriļ¬cation times (timing details were not well represented).
We could deal better with uncertainty or timing constraints
by applying a different model checker.
The model of a person in the robot house was not
represented but this could be incorporated showing their
location for example.
Clare Dixon Veriļ¬cation and Validation Robotic Assistants 18 / 23
19. Introduction Techniques and Approach The Domestic Scenario The Manufacturing Scenario Conclusions
Experiments with Trust and Reliability
In the robot house UoH experimented using two scenarios
where the robot appeared faulty or not.
In both scenarios the person was asked to carry out a task with
the robot.
Results suggested that although errors in a robotās behavior are
likely to affect participantās perception of its reliability and
trustworthiness, this doesnāt seem to inļ¬uence their decisions
to comply with instructions (or not).
Their willingness to comply with the
robotās instructions seem to depend
on the nature if the task, in particular,
whether its effects are irrevocable.
Clare Dixon Veriļ¬cation and Validation Robotic Assistants 19 / 23
20. Introduction Techniques and Approach The Domestic Scenario The Manufacturing Scenario Conclusions
The Manufacturing Scenario: Veriļ¬cation
The focus was on a table leg handover task. The gaze, hand
location and hand pressure of the human should be correct
before the handover takes place.
Journal Title XX(X)
All the veriļ¬cation
-world. The models
oneously, or may be
, or relative to one
s. In our approach,
he system are con-
assertions and prop-
quirements models
mulated.
ble that numerical
ļ¬cation results. In
ontain bugs that are
āExperiments.ā As
the textual require-
experimentation. At
formal veriļ¬cation
e compared against
cover that one of the
ed testing or formal
ents. In this case we
assets, as explained
e between the dif-
cover the cause of
isons are indicated
Formal Veriļ¬cationā
ulation-based Test-
Figure 2. BERT 2 engaged in the handover task.
robot. BERT 2 then picks up a nearby object, and holds
it out to the human. The robot announces that it is ready
to handover. The human responds verbally to indicate that
they are ready to receive. (For practical reasons, human-to-
robot verbal signals were relayed to the robot by a human
operator pressing a key.) Then, the human is expected to
pull gently on the object while looking at it. BERT 2 then
calculates three binary sensor conditions:
ā¢ Gaze: The humanās head position and orientation
relative to the object are tracked using the Vicon R
motion-tracking system for an approximate measure
of whether he/she is looking at the object.
11
RobotController_3S
Modelling was carried out using Probabilistic Timed Automata
and veriļ¬cation via the PRISM probabilistic model checker.
Clare Dixon Veriļ¬cation and Validation Robotic Assistants 20 / 23
21. Introduction Techniques and Approach The Domestic Scenario The Manufacturing Scenario Conclusions
Manufacturing Scenario: Simulation and Experiments
Simulation based testing and real robot experiments (BRL)
12
code to be used in simulation and in the actual robot,
providing consistency between simulations, experiments,
and deployed use. A screenshot of the ROS/Gazebo
simulation can be seen in Figure 5.
For the simulator, additional ROS nodes were con-
structed in Python, to simulate BERT 2ās sensor sys-
tems and embedded actuation controllers. The pre-existing
URDF ļ¬le describing BERT 2 was extended as described
previously for use in Gazebo. The simulated human
behaviour was controlled by a ROS node written in Python,
driving a simpliļ¬ed physical model of the head and hand.
Figure 5. Screenshot of the simulated handover task. The
human head and hand are represented in orange. The object
to be handed over is shown in blue.
A testbench was incorporated into the simulator. The
testbench comprised a test generator, a driver, a checker
and a coverage collector. Achieving the exploration of
meaningful and interesting sequences of behaviours from
the robot and its environment in an HRI task is a
challenging task. For this reason, we stimulate the robotās
code in the simulation indirectly through stimulating its
environment (e.g., the personās behaviour) instead, and we
use a combination of model-based and pseudorandom test
generation. Also, to alleviate the complexity of generating
and timing different types of system inputs, the test
generator is based on a two-tiered approach (Araiza-Illan
et al. 2016) where an abstract test is generated ļ¬rst and
then concretized by instantiating low-level parameters. The
high-level actions of the human in the simulator include
sending signals to the robot, or setting abstract parameters
for gaze, location and pressure. Low-level parameters
include the robotās initial pose and the poses and force
vectors applied by the human during the interaction. For
example, we computed an abstract test of high-level actions
for the human, by exploring the model in UPPAALā¤ā¤
, so
that the
robot an
pressure
gaze, pr
released
the hum
The
simulato
monitor
describe
Finally,
triggerin
The s
5.2.1
assertio
in Pyth
If the
machine
to deter
postcon
For e
both ini
if (sens
wait
asse
Note th
be diff
same t
misinter
The
collecte
veriļ¬ed
The nu
triggere
coverag
5.3 E
5.3.1
imental
custom
in Figur
of a sy
unbiase
environ
to repro
safety c
quently,
be inac
such as
ā¤ā¤http:
ā ā https
Prepared using sagej.cls
We carried out a small user valida-
tion study with 10 participants each
carrying out 10 handover tasks.
Clare Dixon Veriļ¬cation and Validation Robotic Assistants 21 / 23
22. Introduction Techniques and Approach The Domestic Scenario The Manufacturing Scenario Conclusions
The Manufacturing Scenario: Discussion
A number of properties checked inspired by the ISO
requirements, e.g. āAt least 95% (60%) of handover
attempts should be completed successfullyā.
Disagreement between outcomes from some of the
techniques meant further investigation and reļ¬nement of
the models was needed:
simulation based testing revealed that the robot sometimes
dropped the table leg accidentally (gripper failure) which
was not modelled in the formal veriļ¬cation;
real experiments revealed false negatives for the pressure
sensor and location sensor (they were wrongly reported as
too low/incorrect hand position) not represented elsewhere.
Some of the techniques were not suitable for verifying
some of the requirements, for example for aspects such as
speed or closeness formal veriļ¬cation may not be the best
technique to use.
Clare Dixon Veriļ¬cation and Validation Robotic Assistants 22 / 23
23. Introduction Techniques and Approach The Domestic Scenario The Manufacturing Scenario Conclusions
Concluding Remarks
We gave an overview to the research carried out on the project
Trustworthy Robotic Assistants and discussed approaches to
trust and safety for robotic assistants.
We advocate the use of a suite of veriļ¬cation and validation
techniques at different levels of abstraction and coverability to
help gain assurance of the robotās safety, reliability and
functional correctness.
We considered the combination of formal veriļ¬cation (model
checking), simulation-based testing, and user validation in
experiments with real robots in a domestic and collaborative
manufacturing scenario.
Papers available at www.robosafe.org
Clare Dixon Veriļ¬cation and Validation Robotic Assistants 23 / 23