In this paper we present a novel approach for real-time anomaly detection in the flexible production, an emerging area in the manufacturing, esp. in the context of Industry4.0. It is based on an advanced usage of Complex Event Processing combined with the massive data analytics, which enables learning of the clusters, which represent normal/usual and unusual/anomalous behaviour. The main innovation is in the combination of the model-based and data- driven approaches, which enables a continuous anomaly detection. The approach has been implemented using the D2Lab (Data Diagnostics Laboratory) framework for big data processing. The results have been tested in an industry case study, enabling efficient anomaly detection in the shoe manufacturing.

A dragline-forming technology has been previously proposed to enable locomotion through an open-space where no solid surfaces present. The technology is intended for situations where payload requirements are unanticipated. In those situations, variability in dragline's diameter can minimize the use of material hence increase self-sufficiency of the robot. In a previous study, a robot was designed, prototyped and proven to be able to descend through an open-space by forming a thermoplastic dragline with a diameter range of 1.1-4.5 mm. However, the speed of locomotion was rather low due to the lack of an adequate control method for thermoplastic dragline formation. In this paper, models of mass flow and thermodynamics along dragline formation pathway are presented. The models are validated in a newly prototyped robot which forms a dragline continuously. Experiment results show that, when compared to the previous prototype and control method which consists of repeated sequences of discrete events, the speed of descending locomotion is significantly increased and reaches 12.0 cm/min.

Profilers help developers to find and fix performance problems. But do they find performance bugs -- performance problems that real users actually notice? In this paper we argue that -- especially in the case of interactive applications -- traditional profilers find irrelevant problems but fail to find relevant bugs.

Many computer systems are interactive in some way, that means they are used by human users. A human user perceives the performance of a computer system primarily in terms of its response time. If a system does not respond to a user's input, such as a key press, a mouse motion, or a gesture on a touch screen, within roughly 100 ms, a user perceives the system as sluggish. Developers of interactive software and systems thus are interested in keeping response times below this perceptibility threshold. Existing tools allow the measurement of interactive response times, and the tracing of application behavior. In this paper we present a tool, LagAlyzer, which analyzes and visualizes the information gathered by such latency measurement tools. LagAlyzer enables the characterization of perceptible lag, for example by quantifying to what degree perceptible performance was caused by synchronization bottlenecks, by garbage collection, by the runtime libraries, or by the application. We use LagAlyzer to characterize the perceptible latency found in commonly used interactive Java applications. We believe that this is the first study giving insight into why interactive Java applications sometimes are perceived as sluggish.

Many experimental performance evaluations depend on accurate measurements of the cost of executing a piece of code. Often these measurements are conducted using infrastructures to access hardware performance counters. Most modern processors provide such counters to count micro-architectural events such as retired instructions or clock cycles. These counters can be difficult to configure, may not be programmable or readable from user-level code, and can not discriminate between events caused by different software threads. Various software infrastructures address this problem, providing access to per-thread counters from application code. This paper constitutes the first comparative study of the accuracy of three commonly used measurement infrastructures (perfctr, perfmon2, and PAPI) on three common processors (Pentium D, Core 2 Duo, and AMD ATHLON 64 X2).