Feature: Cobots Figure 1: Complex operational setup for cobots on the factory floor
like Walmart are already using robots to clean their stores, with the potential for oversized roombas to clean schools, business premises and hospitals. As cobots work in proximity to
human staff, it’s important that the they work all the time in a deterministic way to guarantee operator safety. Safety certifications and processes need to be defined and strictly observed if this market is to form successfully. This is an area where a lot of focus is on AI to improve cooperation with these machines. It also means there must be a secure way to deliver software updates to add new capabilities to these platforms. For some of the larger platforms, there
are moves toward greater modularity, enabling hardware upgrades over time. Manufacturers don’t want to be tied to a specific hardware vendor, especially in an area as dynamic as artificial intelligence, where in the next few years there might be many business changes, such as acquisitions, companies ceasing to trade, and changes to performance leadership rankings.
IT/OT consolidation Key consideration in cobot design is the consolidation of IT with operational technology (OT), blending robot instructions with factory operation. In a factory the rate of change is relatively slow, since the focus is on reliability, which translates to increased uptime, reduced accidents, less scrap, and so on. OT is therefore separate networks that get connected to IT networks at a main console level. The desire is to push this IT/OT fusion out onto the factory floor, so that machines can make more informed decisions more quickly. This challenge has to be addressed in the context of cost, power and footprint to make the cobot proposition commercially attractive. This implies shrinking multiple systems onto a single consolidated board – and, increasingly, a single heterogeneous multicore chip. These systems need to run rich operating systems like Linux and Windows, whilst also guaranteeing the platform’s stable operation; they are referred to as mixed-criticality systems. Applications must be compartmentalised to ensure that some of them don’t fail any part of the system.
38 September/October 2020
www.electronicsworld.co.uk
Real-time systems based on a single
core processor (SCP) are well understood in industry, which has adopted real-time system engineering processes built on the assumption of constant worst-case execution time (WCET). This states that the measured worst-case execution time of a software task when executed alone on a single core is the same when that task runs together with other tasks. This fundamental assumption is the foundation for the schedulability analysis, determining that a scheduling sequence can be found to complete all the tasks within deadlines. In industry, the technological trend
toward adopting multicore processor (MCP) systems is already well established. Many of these multicore systems have been designed with the speed and efficiency requirements of IT applications in mind, and do not always respect the predictability requirements of control systems in avionics, automotive, industrial automation, and others. In fact, whilst the assumption of a constant WCET is correct for single-core chips, it is not true for current multicore chips, due to interference across cores in accessing shared resources. Interference
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44 |
Page 45 |
Page 46 |
Page 47 |
Page 48 |
Page 49 |
Page 50 |
Page 51 |
Page 52 |
Page 53 |
Page 54 |
Page 55 |
Page 56 |
Page 57 |
Page 58 |
Page 59 |
Page 60 |
Page 61 |
Page 62 |
Page 63 |
Page 64 |
Page 65 |
Page 66 |
Page 67 |
Page 68
