Static Data Race Detection in Multi-task Programs for Industrial Robots

In this paper, we describe a static analysis approach to detect potential runtime errors for a programming language that is used to program industrial robots. The language we deal in this paper is RAPID, a high level programming language for programming ABB industrial robots. The presence of real-time interrupts, exception handlers and complex data-types makes it a difficult language for general purpose static analyzers. The properties of interest include some generic programming errors as well as some domain-specific properties that the robot system must comply with. Generic programming errors include properties like integer overflow, array access out of bounds and division by zero. An example of a domain-specific property is defining boundary limits for robotic arm movement. We have developed a tool to detect these errors successfully in the presence of real-time interrupts.

Shared-memory based parallel programming with OpenMP and Posix-thread APIs becomes more common to fully take advantage of multiprocessor computing environments. One of the critical risks in multithreaded programming is data races that are hard to debug and greatly damaging to parallel applications if they are uncaught. Although ample effort has been made in building specialized data race detection techniques, the state of art tools such as the Intel Thread Checker still have various functionality and performance problems. In this paper, we present a Versatile On-the-fly Race Detection (VORD) tool that provides an agile, efficient, and scalable race detection environment for various parallel programming models. VORD can automatically construct an empirically optimal set of race engines by utilizing classification and adaptation mechanisms. A Race-Detection Classification (RDC) table is created to categorize adequate engines in the aspect of labeling, detecting, and filtering. An Engine Code Property Selector (ECPS) uses the RDC table to adapt optimal engines for the given target programming models. In addition to RDC and ECPS, we have also implemented an OpenMP parser and a source instrumentor. The functionality and efficiency of VORD were compared with those of the Intel Thread Checker by using a set of OpenMP based kernel programs. The experimental results show that VORD can detect data races in more challenging programming models such as nested thread and synchronization models, and can achieve a couple of orders of a magnitude faster processing time than the Intel Thread Checker in the large parallel programs.

Detecting data races in multithreaded programs is a crucial part of debugging such programs, but traditional data race detectors are too slow to use routinely. This paper shows how to speed up race detection by spreading the work across multiple cores. Our strategy relies on uniparallelism , which executes time intervals of a program (called epochs ) in parallel to provide scalability, but executes all threads from a single epoch on a single core to eliminate locking overhead. We use several techniques to make parallelization effective: dividing race detection into three phases, predicting a subset of the analysis state, eliminating sequential work via transitive reduction, and reducing the work needed to maintain multiple versions of analysis via factorization. We demonstrate our strategy by parallelizing a happens-before detector and a lockset-based detector. We find that uniparallelism can significantly speed up data race detection. With 4x the number of cores as the original application, our strategy speeds up the median execution time by 4.4x for a happens-before detector and 3.3x for a lockset race detector. Even on the same number of cores as the conventional detectors, the ability for uniparallelism to elide analysis locks allows it to reduce the median overhead by 13% for a happens-before detector and 8% for a lockset detector.

On-line knowledge acquisition and enhancement in robotic assembly tasks

With the development of the network, there are more and more multi-thread programs. Multi-thread applications have complex operating states and suffer from data race problem. However, the existing data race detection algorithms are mostly based on dynamic methods, which cause high memory overheads. In this paper, we present DR-Frame, a static data race detector that costs lower memory and time. DR-Frame first compiles the program into an intermediate code file. Then DR-Frame simulates the code file to obtain the read and write information of the program. Finally, DR-Frame checks the data observed and detects data race of the original program. We have validated DR-Frame using three real-world network applications and the PARSEC benchmark suite. The experimental results show that DR-Frame can detect new race cases with low memory overheads, and the time cost is less than executing the program.

Data races are a primary source of concurrency bugs in parallel programs. Yet, debugging data races is not easy, even with a large amount of data race detection tools. In particular, there still exists a manually-intensive and time-consuming investigation process after data races are reported by existing race detection tools. To address this issue, we present OMPSanitizer in this paper. OMPSanitizer employs a novel and semantic-aware impact analysis mechanism to assess the potential impact of detected data races so that developers can focus on data races with a high probability to produce a harmful impact. This way, OMPSanitizer can remove the heavy debugging burden of data races from developers and simultaneously enhance the debugging efficiency. We have implemented OMPSanitizer based on the widely-used dynamic binary instrumentation infrastructure, Intel Pin. Our evaluation results on a broad range of OpenMP programs from the DataRaceBench benchmark suite and an ECP Proxy application demonstrate that OMPSanitizer can precisely report the impact of data races detected by existing race detectors, e.g., Helgrind and ThreadSanitizer. We believe OMPSanitizer will provide a new perspective on automating the debugging support for data races in OpenMP programs.

Additive manufacturing or 3D printing slowly and steadily replaces traditional subtractive manufacturing, where parts are manufactured by sequentially removing pieces of the workpiece material. In 3D printing, the material is added in layers, which enables producing parts of complex geometric shapes made from expensive metals with higher productivity and economic efficiency. In order to perform 3D printing on an industrial scale, it is necessary to combine robotics with 3D printing software. This article presents the results of the process design for 3D printing of a compressor impeller prototype. A detailed methodology of customization of the KUKA industrial robot for the 3D printing process is given. Once the impeller model was created in the CAD environment, it was cut into layers in the slicer program. Special software for offline programming of industrial robots was used to translate the program into the robot language and perform 3D printing using an experimental robotic complex. As a result, a prototype of a low-carbon steel compressor impeller was printed using a welding machine and steel wire. The developed technological process was successful and proved that an industrial robot combined with a welding machine can be used as an industrial 3D printer for printing real machine parts.

Detecting data races in multi-threaded programs is a challenging problem in debugging, because the races could reveal nondeterministic program behavior in execution of such programs. Nondeterministic runtime effects of a race are hard to identify and it is difficult to decide whether the reported data races can appear or not in the actual program executions. Previous techniques for detecting races cannot provide method to locate first races in parallel programs with random synchronization including lock/unlock mechnism. This paper presents an algorithm which extracts first races by replaying the program and checking concurrency between sequenced traced data and candidate accesses, which are from a particular execution of parallel programs. We also present the correctness of our algorithm by showing that all the first races are included in the traced accesses which are composed of key accesses.

In this paper we present Caesar, an intelligent domestic service robot. In domestic settings for service robots complex tasks have to be accomplished. Those tasks benefit from deliberation, from robust action execution and from flexible methods for human---robot interaction that account for qualitative notions used in natural language as well as human fallibility. Our robot Caesar deploys AI techniques on several levels of its system architecture. On the low-level side, system modules for localization or navigation make, for instance, use of path-planning methods, heuristic search, and Bayesian filters. For face recognition and human---machine interaction, random trees and well-known methods from natural language processing are deployed. For deliberation, we use the robot programming and plan language Readylog, which was developed for the high-level control of agents and robots; it allows combining programming the behaviour using planning to find a course of action. Readylog is a variant of the robot programming language Golog. We extended Readylog to be able to cope with qualitative notions of space frequently used by humans, such as "near" and "far". This facilitates human---robot interaction by bridging the gap between human natural language and the numerical values needed by the robot. Further, we use Readylog to increase the flexible interpretation of human commands with decision-theoretic planning. We give an overview of the different methods deployed in Caesar and show the applicability of a system equipped with these AI techniques in domestic service robotics.

Data races are a prevalent class of concurrency bugs in shared-memory parallel programs, posing significant challenges to software reliability and reproducibility. While there is an extensive body of research on detecting data races and a wealth of practical detection tools across various programming languages, considerably less effort has been directed toward automatically fixing data races at an industrial scale. In large codebases, data races are continuously introduced and exhibit myriad patterns, making automated fixing particularly challenging. In this paper, we tackle the problem of automatically fixing data races at an industrial scale. We present Dr.Fix, a tool that combines large language models (LLMs) with program analysis to generate fixes for data races in real-world settings, effectively addressing a broad spectrum of racy patterns in complex code contexts. Implemented for Go—the programming language widely used in modern microservice architectures where concurrency is pervasive and data races are common—Dr.Fix seamlessly integrates into existing development workflows. We detail the design of Dr.Fix and examine how individual design choices influence the quality of the fixes produced. Over the past 18 months, Dr.Fix has been integrated into developer workflows at Uber demonstrating its practical utility. During this period, Dr.Fix produced patches for 224 (55%) from a corpus of 404 data races spanning various categories; 193 of these patches (86%) were accepted by more than a hundred developers via code reviews and integrated into the codebase.

This is the 23rd Self-Assessment Procedure. 1 The purpose of this procedure is to let its readers test their knowledge of some of the more important features of significant programming languages. The features of imperative languages like Fortran, Algol 60, PL/I, Pascal, Modula-2, C, and Ada considered are data types, data structures, control structures, program units, scope of names, and parameter passing. Some of the corresponding features of functional languages like Lisp, logic programming languages like Prolog, and ohject-oriented programming languages like C++ and Smalltalk, are reviewed. Finally brief consideration is given to syntax and semantics, chiefly by reference to the Backus-Naur form, BNF. The features of programming languages affect all aspects of programming, including the ease of writing and maintaining programs, the reliahility of software, and the efficiency and portability of programs. Knowledge of programming language concepts and constructs is of importance to software developers, programmers, and designers of programming languages and compilers. The topic of this procedure should be of interest to any computer science student or practitioner who wishes to test his or her knowledge and learn more about one of the most important and broad areas in the computer field. The language used most often in the questions is Pascal, with Ada, Lisp, and Prolog also featured prominently. A glossary is included which defines some of the terms used in the procedure. The questions are either multiple-choice or short answer. Some of the multiple-choice questions allow for more than one correct answer.

The ARINC-653 standard architecture for flight software specifies an application executive (APEX) which provides an application programming interface and defines a hierarchical framework which provides health management for error detection and recovery. In every partition of the architecture, however, asynchronously concurrent processes or threads may include concurrency bugs such as unintended race conditions which are common and difficult to remove by testing. A race condition toward a shared data, or data race, is a pair of unsynchronized instructions that access a shared variable with at least one write access. Data races threaten the reliability of shared-memory programs seriously and latently, because they result in unintended nondeterministic executions of the programs. To heal data race during executions of ARINC-653 flight software, this paper instruments on-the-fly race detection into the target program and incorporates on-the-fly race healing into the health management of the ARINC-653 architecture. The race detection signals to the health monitor using the corresponding APEX call, if a data race is detected. The health monitor then responds by invoking an aperiodic, user-defined, error handling process that is assigned the highest possible priority. This special process uses an APEX call to identify and then heals the occurrence of race condition as an application error, one of seven error types defined by ARINC-653. This race-healing process allows the target programs to be assured at run-time that the execution result of the healed program could have been in the original program and therefore no new functional bug has been introduced. This paper evaluates efficiencies of the on-the-fly mechanisms to argue that they are practical to be configured under the ARINC-653 partitions.

Programming environments for smartphones expose a concurrency model that combines multi-threading and asynchronous event-based dispatch. While this enables the development of efficient and feature-rich applications, unforeseen thread interleavings coupled with non-deterministic reorderings of asynchronous tasks can lead to subtle concurrency errors in the applications. In this paper, we formalize the concurrency semantics of the Android programming model. We further define the happens-before relation for Android applications, and develop a dynamic race detection technique based on this relation. Our relation generalizes the so far independently studied happens-before relations for multi-threaded programs and single-threaded event-driven programs. Additionally, our race detection technique uses a model of the Android runtime environment to reduce false positives. We have implemented a tool called DroidRacer. It generates execution traces by systematically testing Android applications and detects data races by computing the happens-before relation on the traces. We analyzed 15 Android applications including popular applications such as Facebook, Twitter and K-9 Mail. Our results indicate that data races are prevalent in Android applications, and that DroidRacer is an effective tool to identify data races.

A reconfigurable robot is a robot that can change shape. Programming reconfigurable robots is complicated by the need to adapt the behavior of each of the individual module to the overall physical shape of the robot. In this position paper, we investigate a simple approach to allow the programmer to abstract over the concrete shape of a robot using the notion of a label as a simple means of addressing various parts of the structure of a robot. Labels provide the programming language designer with a means of stratifying two main components of a spatial programming language for modular robots, namely specifying the physical structure of a robot and specifying its behavior. Based on previous experience with the ATRON robot, we find that labels are a useful concept for programming modular robots.

The block-based approach to programming is an effective way to engage young learners in programming and the powerful ideas of computing. In this paper, we explore the potential of using this same approach in a very different programming context: industrial robotics. Using a customized language built with the Blockly library, we created a block-based interface for programming a one-armed industrial robot. This paper presents a block-based robot programming language called Robot Blockly, focusing on how the various affordances of block-based programming were utilized to make the challenge of robot programming more accessible. We also present results from a small-scale study showing adults with no prior programming experience successfully programming a virtual robot to accomplish a pick and place task. The contribution of this work is in showing the potential for block-based programming beyond young learners and classrooms.