Abstract

This chapter discusses man-machine interface. PLC has to “connect” to human operators, accepting commands from them and displaying the status of the plant in a form that can readily and easily be understood. A digital display driven in BCD normally uses one of the unused binary codes, 1010 to 1111, to generate a blank display. Simple digital inputs (pushbuttons, joysticks, switches) are normally allocated one input per motion and do not require anything particularly special. Concerning PLC with analog signals, flows, temperatures, pressures, etc., these will usually be displayed to the operator. A graphics terminal has just two connections to the outside world, a serial link connection and a power supply. The Allen Bradley Panelview family was designed to replace switches, pushbuttons, numeric displays, and similar devices. The Panelview built up a graphics screen with semigraphic characters placed on a screen with a “pick and place” menu approach. Siemens provides a vast range of operator terminals from simple text-only message displays to complete computer-based Scada systems. One major advantage of graphical displays is that mistakes can be rectified without leaving scars, albeit at some cost. The operator will need to input data and initiate actions. Where a simple text message is to be displayed, possibly with embedded data, message displays driven by a simple serial link carrying ASCII coded characters can be used. PCs have much better graphics capability than the average PLC, so it is not surprising that PCs are increasingly being used as the link between humans and PLC systems. Document type: Part of book or chapter of book

Abstract

A study was made of the flow of data and the simultaneous processing needed to reduce the 10/sup 7/ to 10/sup 8/ triggers per second expected at ISABELLE to a number of events on the order of 10 to 100 per second which would be written on magnetic tape. It was assumed that within 100 ns of the event a fast pretrigger would have reduced the data rate to at most 10/sup 7/ per second. At that point, data from all sense elements in the experiment would be fed into a 1-..mu..s-long pipeline. Within the first 1 ..mu..s (while the data are in the first pipeline) another level of triggering would reduce the trigger rate to at most 10/sup 6/ per second. The data would then be fed into a second pipeline which is 50 ..mu..s long. During the 50 ..mu..s the data are in the second pipeline, a more sophisticated level of triggering (slow trigger) would reduce the trigger rate to a level that can be handled by standard data processing techniques (microprocessors or larger machines), i.e., 10/sup 2/ to 10/sup 3/ per second. The pipelines and the buffer between them, a sequential address memory, are described first, andmore » then several alternative schemes for the pretrigger and slow trigger are presented. 10 figures.« le Document type: Report

Abstract

Conference of 10th IEEE International Symposium on Industrial Embedded Systems, SIES 2015 ; Conference Date: 8 June 2015 Through 10 June 2015; Conference Code:116797; International audience; Many-core architectures are promising hardware to design hard real-time systems as they are based on simpler and thus more predictable processors than multi-core systems. However, the worst-case behavior of the Network-on-Chip (NoC) for both inter-core and core to external memories or peripherals communications must be established. Several NoCs targeting hard real-time systems, made of specific hardware extensions, have been designed. However, none of these extensions are currently available in commercially existing NoC-based many-core architectures, that instead rely on wormhole switching with round-robin arbitration. In this paper, we thus demonstrate three properties of such NoC-based wormhole networks to identify worst-case scenarios and reduce the pessimism when modeling flows in contentions. We then describe and evaluate an algorithm to compute Worst-Case Traversal Time (WCTT) of flows that uses these properties. In particular, our results show that the pessimism can be reduced up to 50% compared to current state-of-the-art real-time packet schedulability analysis.

Abstract

This paper presents a new method for the design and validation of advanced driver assistance systems (ADASs). With vehicle hardware-in-the-loop (VEHIL) simulations, the development process, and more specifically the validation phase, of intelligent vehicles is carried out safer, cheaper, and is more manageable. In the VEHIL laboratory, a full-scale ADAS-equipped vehicle is set up in a hardware-in-the-loop simulation environment, where a chassis dynamometer is used to emulate the road interaction and robot vehicles to represent other traffic. In this controlled environment, the performance and dependability of an ADAS is tested to great accuracy and reliability. The working principle and the added value of VEHIL are demonstrated with test results of an adaptive cruise control and a forward collision warning system. On the basis of the 'V' diagram, the position of VEHIL in the development process of ADASs is illustrated.