DCS and PLC/SCADA

Traditionally, DCSs were large, expensive and very complex systems that were considered as a control solution for the continuous or batch process industries. In large systems this is, in principle, still true today, with engineers usually opting for PLCs and HMIs or SCADA for smaller applications, in order to keep costs down. 

So what has changed? Integrating independent PLCs, the required operator interface and supervisory functionality, takes a lot of time and effort. The focus is on making the disparate technology work together, rather than improving operations, reducing costs, or improving the quality or profitability of a plant. 

 Yet a PLC/ SCADA system may have all or part of the following list of independent and manually coordinated databases. 

* Each controller and its associated I/O 

* Alarm management 

* Batch/recipe and PLI 

* Redundancy at all levels 

* Historian 

* Asset optimisation 

* Fieldbus device management 

Each of these databases must be manually synchronised for the whole system to function correctly. That is fine immediately after initial system development. However, it becomes an unnecessary complication when changes are being implemented in on-going system tuning and further changes made as a result of continuous improvement programmes.

Making changes

Every time a change is made in one database, the others usually need to be updated to reflect that change. For example, when an I/O point and some control logic are added there may be a need to change or add a SCADA element, the historian and the alarm database. This will require the plant engineer to make these changes in each of these databases, not just one – and get it right.

In another scenario, a change may be made in an alarm setting in a control loop. In a PLC implementation there is no automatic connection between the PLC and the SCADA/ HMI. This can become a problem during start up of a new application, where alarm limits are being constantly tweaked in the controller to work out the process, while trying to keep the alarm management and HMI applications up to date with the changes and also being useful to the operator. 

Today’s DCS, which are also sometimes called ‘process control systems,’ are developed to allow a plant to quickly implement the entire system by integrating all of these databases into one. This single database is designed, configured and operated from the same application.

This can bring dramatic cost reductions when using DCS technology, when compared with PLC/ SCADA (or HMI): at least in the cost of engineering. DCS hardware has always been considered as being large and expensive. This is certainly no longer the case today. DCS hardware even looks like a PLC, and the software runs on the same specification PC, with the same networking – so why the extra cost? Is it the software? Although it is true to say that DCS software can be made to be expensive – but only by buying all of the many advanced functional features that are available – and often that you would not use or need! 

Where smaller and medium systems are concerned, then price comparisons on acquiring hardware and software are comparable to PLC/SCADA. So, the real difference is actually in the costs associated with the workflow – which is enhanced and simplified by the single database at the heart of a DCS.

At this point one may think that DCS functionality is biased towards control loops, whilst PLCs are biased towards discrete sequential applications and that this, therefore, is not a like-for-like comparison. This is another myth. A DCS today is just as functionally and cost-effective as a PLC in fast logic sequential tasks. 

Demonstrating advantages

ABB was able to offer CEE some examples to demonstrate how savings can be realised by using today’s DCS workflow, when compared with a PLC/HMI (SCADA) system. The company has compiled the information from decades of implementation expertise of ABB engineers, end-user control engineers, consultants and multiple systems integrators who actively implement both types of control solutions based on application requirement and user preferences. It is easier to structure this explanation along a generic project development sequence of tasks.

Step 1: System design

PLC/ SCADA control engineers must map out system integration between HMI, alarming, controller communications and multiple controllers for every new project. Control addresses (tags) must be manually mapped in engineering documents to the rest of the system. This manual process is time consuming and error prone. Engineers also have to learn multiple software tools, which can often take weeks of time.

DCS approach: As control logic is designed, alarming, HMI and system communications are automatically configured. One software configuration tool is used to set up one database used by all system components. As the control engineer designs the control logic, the rest of the system falls into place. The simplicity of this approach allows engineers to understand this environment in a matter of a few days. Potential savings of 15 - 25% depending on how much HMI and alarming is being designed into the system.

Step 2: Programming

PLC/ SCADA control logic, alarming, system communications and HMI are programmed independently. Control engineers are responsible for the integration/ linking of multiple databases to create the system. Items to be manually duplicated in every element of the system include: scalability data, alarm levels, and Tag locations (addresses). Only basic control is available. Extensions in functionality need to be created on a per application basis (e.g. feed forward, tracking, self-tuning, alarming). This approach leads to non-standard applications, which are tedious to operate and maintain. Redundancy is rarely used with PLCs. One reason is the difficulty in setting it up and managing meaningful redundancy for the application. 

The DCS way: When control logic is developed, HMI faceplates, alarms and system communications are automatically configured. Faceplates automatically appear using the same alarm levels and scalability set up in the control logic. These critical data elements are only set up once in the system. This is analogous to having your calendars on your desktop and phone automatically sync vs. having to retype every appointment in both devices. People who try to keep two calendars in sync manually find it takes twice the time and the calendars are rarely ever in sync. Redundancy is set up in software quickly and easily, nearly with a click of a button. Potential savings of 15 - 45%

Step 3: Commissioning and start-up

Testing a PLC/ HMI system is normally conducted on the job site after all of the wiring is completed and the production manager is asking “why is the system not running yet?” Off line simulation is possible, but this takes an extensive effort of programming to write code which will simulates the application you are controlling. Owing to the high cost and complex programming, this is rarely done.

DCS benefits: Process control systems come with the ability to automatically simulate the process based on the logic, HMI and alarms that are going to be used by the operator at the plant.

This saves significant time on-site since the programming has already been tested before the wiring is begun. Potential savings are 10 - 20% depending on the complexity of the start up and commissioning.

Step 4: Troubleshooting

PLC/ SCADA offers powerful troubleshooting tools for use if the controls engineer programs them into the system. For example, if an input or output is connected to the system, the control logic will be programmed into utilising the control point. But when this is updated, did the data get linked to the desperate HMI? Have alarms been set up to alert operators of problems? Are these points being communicated to the other controllers? Programming logic is rarely exposed to the operator since it is in a different software tool and not intuitive for an operator to understand.

The DCS way: All information is automatically available to the operator based on the logic being executed in the controllers. This greatly reduces the time it takes to identify the issues and get your facility up and running again. The operator also has access to view the graphical function blocks as they run to see what is working and not (read only). Root Cause Analysis is standard. Field device diagnostics (HART and fieldbus) are available from the operator console. Potential savings of 10 - 40% (This varies greatly based on the time spent developing HMI and alarming, and keeping the system up to date.)

Step 5: The ability to change to meet process requirements

PLC/ SCADA: Changing the control logic to meet new application requirements is relatively easy. The challenge comes with additional requirements to integrate the new functionality to the operator stations. Also, documentation should be developed for every change. This does not happen as frequently as it should. If you were to change an input point to a new address or tag, that change must be manually propagated throughout the system.

The DCS way: Adding or changing logic in the system is also easy. In many cases even easier to change logic with built in and custom libraries of code. When changes are made, the data entered into the control logic is automatically propagated to all aspects of the system. This means far less errors and the system has been changed with just a single change in the control logic.

Potential savings of 20 - 25% on changes is not uncommon. This directly affects continuous improvement programmes. 

Step 6: Operator training

With PLC/ SCADA operator training is the responsibility of the developer of the application. There is no operator training from the vendor since every faceplate, HMI screen or alarm management function can be set up differently from the next. Even within a single application, operators could see different graphics for different areas of the application they are monitoring. 

The DCS way: Training for operators is available from the process control vendor. This is owing to the standardised way that information is presented to operators. This can significantly reduce operator training costs and quality due to the common and expected operator interface on any application, no matter who implements the system. This can commonly save 10 -15 percent in training costs which can be magnified with the consistency found across operators and operator stations.

Step 7: System documentation

PLC/SCADA documentation is based on each part of the overall system. As each element is changed, documentation must be created to keep each document up to date. Again, this rarely happens, causing many issues with future changes and troubleshooting.

The DCS way: As the control logic is changed, documentation for all aspects of the system is automatically created. This can save 30 - 50 percent depending on the nature of the system being put in place. These savings will directly minimise downtime recovery.

Time saving estimates are based on typical costs associated with a system using ~500 I/O, Two controllers, one workstation and 25 PID Loops.

Conclusion

If you are using, or planning to use, PLCs and HMI/ SCADA to control your process or batch applications, your application could be a candidate for the use of a DCS solution to help reduce costs and gain better control. The developer can concentrate on adding functionality that will provide more benefits, reducing the return on investment payback period and enhancing the system’s contribution for years to come. The divide between DCS and PLC/ SCADA approaches is wide, even though some commonality at the hardware level can be observed; the single database is at the heart of the DCS benefit and is a feature that holds its value throughout its life. The new economic proposal may be a DCS, says ABB.

Source : - http://www.controlengeurope.com/article/40827/DCS-and-PLC-SCADA-a-comparison-in-use.aspx

Greater Integration Between the SCADA and DMS

Moves towards a smarter grid are seen in the form of greater integration between the SCADA and DMS throughout the transmission network and medium-voltage equipment. Moreover, as utilities roll-out Advanced Metering Infrastructure (AMI), the integration of AMI data with the DMS is a defining aspect of the smart grid. The integration of AMI data with DMS applications is expected to deliver benefits such as shorter outage duration, better management of system loading, and improved voltage profiles. From the customer’s perspective, smart meters are intended to increase awareness of energy usage, including real-time and historical information, which should help reduce overall energy consumption. This simplifies network-management challenges for utility companies, while empowering consumers to reduce their own energy bills.

Smartening the distribution network

A growing number of smart devices are being installed in substations and distribution systems. These include intelligent controls for voltage regulators used for volt/VAR control, and line reclosers and switches used for tasks such as automatic switching, fault isolation, and automatic restoration after temporary faults.

The use of serial communication protocols for communicating with intelligent controllers, or integrated devices such as smart reclosers, is giving way to Ethernet-based networking using the latest IEC 61850 communication standard. In addition to promoting interoperability and eliminating protocol diversity, IEC 61850 incorporates the GOOSE (Generic Object Oriented Substation Events) protection-speed messaging protocol, which enables high-speed protection, transfer switching, fault isolation, and service restoration. The high speed of the GOOSE protocol allows intelligent controllers or smart reclosers communicating on a peer-to-peer basis to identify the location of a fault, and therefore avoid the voltage disturbances caused by repeated actuation of conventional reclosers. When the fault is pinpointed, the operator can take the correct remedial action to restore service and repair the fault.

To implement comprehensive measurement, protection and automation functionalities at the recloser level, multiple voltage sensors and current transformers are required. Current transformers are used to measure the current in each phase accurately. CR Magnetics has a range of commercial and metering-class current transformers, which can be used for various monitoring and fault-detection duties and includes devices rated up to 4000 A. The metering-class transformers provide high accuracy and minimum phase-angle error. Current transformers allow non-contact monitoring of the current in a conductor by passing the conductor through the transformer’s central window. The CR Magnetics range features square and circular current transformers including the CR7310, which can be used for detecting ground faults or other causes of 3-phase imbalance. All three phases and neutrals are routed through the transformer window, and the sum of the 3-phase Y currents is expected to be zero when the loads are equal. If there is an imbalance, the phases do not cancel and the relay trips.

Smart meters reach the customer

While IEC 61850 communication over Ethernet is becoming more widely used at the substation and feeder level, power line communication (PLC) using a protocol such as IEC 61334, PRIME (PoweRline Intelligent Metering Evolution), or G3-PLC enables utilities to leverage their existing power line infrastructure to communicate with smart meters installed at customer premises. Low-frequency narrowband PLC is typically used, at frequencies up to 500 kHz.

The underlying functional elements of a smart meter, which comprise analog measurement, processing and communications, may be implemented using discrete Analog Front-End (AFE), processor and communication modem components, or using a more integrated approach.

Texas Instruments’ TMS320F28 PLC microcontroller seeks to simplify design while preserving flexibility by integrating the PLC modem functionality and providing a development platform including a PLC modem hardware-configuration tool and the plcSUITE™ software framework. This platform allows developers to quickly develop and test robust PLC implementations and provides flexibility to separate the modulation implementation, the protocol design, and the development of the application. The platform provides a graphical user interface that helps developers visualize and fine-tune key PLC modem performance parameters. Combined, this modular hardware architecture and flexible software framework creates the industry’s only PLC technology capable of supporting multiple standards and modulation schemes with a single platform. Developers can use this platform to create a variety of PLC solutions for smart-energy applications, as shown in Figure 2, with the flexibility to adapt as the applicable standards evolve.

Figure 2: PLC technology is ideal for a wide range of smart-energy devices for consumer, municipal, and transmission applications.

STMicroelectronics has combined processing functionality, PLC modem, and analog front-end into a single System-on-Chip (SoC) device in its STarGRID family of PLC SoCs. As Figure 3 illustrates, the STarGRID platform includes an 8051 processor core for protocol control duties, combined with a separate DSP, giving the flexibility to support multiple modulation schemes. The power line driver, analog front-end, and auxiliary functions such as power and clock management are also integrated. The family of devices includes the ST7580, which is currently being used in 13 million smart meters by the utility companies ENEL and ENDESA, which have operations in southern Europe and Latin America. A similar device, the ST7590, is certified by the PRIME Alliance and used by the Spanish energy group Iberdrola in the 11 million meters deployed as part of its STAR project.

Figure 3: Key functional elements of the STarGRID® narrowband SoC platform.

Controlling the new functionality

The design of today’s electronic smart meters takes advantage of remote communications, via PLC or wireless, to implement features and capabilities that have not been possible with traditional electromechanical meters. Among these is the service-disconnect switch, which is used to disconnect a property from the grid for safety reasons such as if the premises are unoccupied or during maintenance or emergencies. By integrating this function as an electronically-controlled switch in the smart meter, it can be actuated from a remote location. This not only allows safety or emergency disconnect instructions to be carried out quickly and efficiently, but also gives utility companies extra flexibility to manage demand and maintain grid stability and voltage levels. The switch is typically a dual-coil polarized latching relay, which requires no holding current to maintain the contacts in either an open or closed state. To ensure reliable delivery of relay-control pulses generated by the microcontroller, and minimize the possibility of tampering, a suitable relay driver such as the Fairchild Semiconductor FAN324x may be used. The FAN3240 has outputs rated for operation from 8 V to 60 V, and integrates a filter/timer block that prevents inadvertent switching from noisy input signals.

Conclusion

The transition to a smart grid is an ongoing process that applies to the entire electricity transmission and distribution network, and has already been taking place for some time. Distribution companies have been using data from SCADA in progressively smarter ways, and driving SCADA further into the network in pursuit of the same goals that are associated with the smart grid as it is understood today. Smart meters capable of providing richer data both to utilities and consumers, represent the final link, bringing smart technology into customers’ premises and general public awareness.

http://www.digikey.com/en/articles/techzone/2013/nov/keeping-the-smart-grid-smart

Achieving Better Embedded Software Performance Through Memory Layout Optimization

Software Engineering for Embedded Systems, Mike Brogioli of Polymathic Consulting provides tips on various memory layout optimization techniques that can be used to improve embedded system performance.

In order to obtain sufficient levels of performance, application developers and software systems architects must not only select the appropriate algorithms to use in their applications, but also the means by which those applications are implemented. Quite often this also crosses the line into data structure design, layout and memory partitioning for optimal system performance.

It is true that senior developers often have insight into both algorithms and their complexity, as well as a toolbox of tips and tricks for memory optimization and data structure optimization. At the same time, the scope of most embedded software engineering projects prohibits manual code and data hand optimization due to time, resource and cost constraints.

As such, developers must often rely on the tools as much as possible to optimize the general use cases, only resorting to hand-level tuning and analysis to tweak performance on those performance-critical bottlenecks after the initial round of development.

This last round of optimization often entails using various system profiling metrics to determine performance-critical bottlenecks, and then optimizing these portions of the application by hand using proprietary intrinsics or assembly code, and in some cases rewriting performance-critical kernel algorithms and/or related data structures. This article follows on from the topics discussed in Part 1 and details design decisions that may prove useful for embedded system developers concerned with the issues those topics mentioned above.

Overview of memory optimization
Memory optimizations of various types are often beneficial to the run-time performance and even power consumption of a given embedded application. As was mentioned previously, these optimizations can often be performed to varying degrees by the application build tools such as compilers, assemblers, linkers, profilers and so forth. Alternatively, it is often valuable for developers to go into the application and either manually tune the performance or design in consideration of memory system optimization a priori, for either given performance targets or so as to design the software architecture to be amenable to automated-tool optimization in subsequent phases of the development cycle.

In tuning a given application, quite often the baseline or “out of box” version of the application will be developed. Once functionality is brought online, the development team or engineers may select to profile the application for bottlenecks that require further optimization. Often these are known without profiling, if certain kernels within the application must execute within a given number of clock cycles as determined by a spreadsheet or pen and paper exercise during system definition. Once these key kernels are isolated or key data structures are isolated, optimization typically begins by those experts with knowledge of both software optimization techniques, compiler optimizations, the hardware target and perhaps details of the hardware target instruction set.

Focusing optimization efforts
Amdahl’s law plays an interesting role in the optimization of full application stacks, however, and is not always appreciated by the software system developer. If only 10% of the dynamic run-time of a given application can benefit from SIMD or instruction-level parallel optimizations versus the 90% of dynamic run-time that must be executed sequentially, then inordinate amounts of effort on parallelizing the 10% portion of the code will still only result in modest performance improvements. Conversely, if 90% of the total application’s dynamic run-time is spent in code regions exhibiting large amounts of instruction-level parallelism and data-level parallelism, it may be worthwhile to focus engineering effort on parallelizing these regions to obtain improved dynamic run-time performance.

In determining those portions of the code which dominate the dynamic application run- time, and may be the best candidates for either hand optimization or hand adjustment for applicability to automated-tool optimization, application developers typically use a software profiler in conjunction with either the silicon target or software-based system simulation. Intel’s VTUNE is one such example of a profiling framework; alternatively the GNU GCC compiler and GPROF are open-source solutions that provide dynamic run-time information. Many silicon vendors such as Freescale Semiconductor and Texas Instruments also offer their own proprietary solutions for use with their respective silicon targets, allowing for either traces collected on software-based simulation platforms, or alternatively larger application-level traces that can be collected on the native silicon target.

Vectorization and the dynamic code: compute ratio
Vectorization of loops is an optimization whereby computation performed across multiple loop iterations can be combined into single vector instructions, effectively increasing the instruction-to-compute ratio within the application’s dynamic run-time behavior. Consider the example in Figure 5.

     short a[16], b[16], c[16];
     for(iter=0; iter<16; ++iter)
     {
          // results in single 16-bit MPY instruction
          // generated in assembly listing
          //
          a[iter] = b[iter] * c[iter]
     }

     short a[16], b[16], c[16]; for(iter=0; iter<16 iter+=4)
     {
          // with high level compiler vectorization,
          // results in 4-WAY parallel 4x16-BIT multiply
          // vector instruction, effectively performing the
          // computation of four iterations of the loop in
          // a single atomic SIMD4 instruction.
          //
          a[iter:iter+4] = b[iter:iter+4] * c[iter:iter+4];
     }

Figure 5: Loop level vectorization example

In the first loop nest, we can see that each iteration of the loop contains a single 16-bit by 16-bit multiply instruction whose result is written to the a[] array as output. One multiplication instruction is performed for each iteration of the loop, resulting in 16 16-bit multiplications. The second loop, however, shows pseudocode for how the compiler or application developer might vectorize the loop when targeting an architecture that supports a four-way SIMD multiply instruction over 16-bit integer elements.

In this case, the compiler has vectorized multiple iterations of the loop together into the multiply instruction, as denoted by the array[start_range:end_range] syntax denoted in the second loop nest. Note that the loop counter is incremented by the vectorized length for each iteration of the loop now. Clearly only four iterations over the loop are now needed to compute the resulting an output array, as each iteration of the loop now contains a single vector multiply instruction that computes four elements of the output vector in parallel.

There are many benefits to vectorizing code in this manner, either by hand if the application developer uses intrinsics that are proprietary with respect to the target architecture, or if the compiler is able to vectorize the code. One such benefit is the increase in performance, as the code now exploits dedicated SIMD hardware, often providing a multiplication in improvement over the vectorized loop on the order of the underlying SIMD vector hardware.

Other benefits are the reduction in code size, as loops are no longer unrolled resulting in explosions in the code size, but rather more dense instructions of vector format are used rather than atomic scalar instructions. This may have secondary benefits in reducing the number of instruction fetch transactions that go out to memory as well. Lastly, the overall ratio of dynamically issued instructions to computation performed within the application is increased as well.

There are a number of challenges to both the development tools and the application developers when trying to vectorize code at the loop level. One such challenge is the code shape of loop nests that are candidate for vectorization. Typically, build tools need to understand the loop iteration space of a loop, so using constant loop bounds rather than run- time computed values may be beneficial depending on the advancement of the underlying compiler’s vectorization technology.

Secondly, the types of computation performed within the loop nest must be amenable to vectorization. For example, in the example above simple 16-bit integer multiplication is performed for a target architecture supporting a supposed 16-bit four-way SIMD multiply instruction. If the underlying target architecture only supports 8-bit SIMD multiplication, it may be advantageous to avoid 16-bit multiplication wherever possible if vectorization is desired.

Loop dependence analysis is another concern when vectorizing or parallelizing loop nests, as the compiler must be able to prove the safety of loop transformations. Loop dependence analysis is the means by which the compiler or dependence analyzer determines whether statements within a loop body form a dependence with respect to array accesses and data modifications, various data reduction patterns, simplification of loop-independent portions of the code and management of various conditional execution statements within the loop body.

As an example, consider the fragment of C-language code in Figure 6.

     for(iter_a=0; iter<LOOP_BOUND_A; ++iter_b)
        for(iter_b=0; iter_b<LOOP_BOUND_B; ++iter_b)
           a[iter_a+4-iter_b] =
              b[2*iter_a-iter_b]+ iter_a*iter_b;

Figure 6: Fragment of C language code

For the loop above, the compiler’s data dependence analyzer will attempt to find all dependences between the statements reading the array b[] and writing to the array a[]. The challenge for the data dependence analyzer is to find all possible dependences between the statements that write to array a[] and read from array b[]. To ensure safety, the data dependence analyzer must ensure that it can explicitly prove safety or, in other words, any dependence that cannot be proven false must be assumed to be true to ensure safety!

The data dependence analysis shows independence between references by proving that no two instances of statements to array a[] and array b[] access or modify the same spot in array a[]. In the event that a possible dependence is found, loop dependence analysis will make an attempt to characterize the dependences, as some types of optimizations over loop nests may still be possible and profitable. It may also be possible to further transform the loop nests so as to remove the dependence.

In summary, writing loop nests so that a minimum of data dependencies exists between array references will benefit vectorization and other loop transforms as much as possible. While the compiler technology used in analyzing data dependencies and autovectorizing serial code for vector hardware stems from the supercomputing community, improperly written code with troublesome data dependencies and loop structure may still thwart the vectorization efforts of the most advanced tool sets.

At a high level, simply writing code which is easiest for humans to understand usually produces code that is easiest for the vectorizer to understand as well, as the vectorizer and data dependence analyzers can easily recognize what the programmer intended. In other words, highly hand-tuned code with a priori knowledge of the underlying target architecture is not the best candidate for automated vectorization at the tools level.

There are a number of things that application developers may want to keep an eye out for when developing code with the intent of autovectorization by the build tools.

Pointer aliasing in C
One challenge for vectorizers and data dependence analysis is the user of pointers in the C language. When data is passed to a function via pointers as parameters, it is often difficult or impossible for the data dependence analyzer and subsequent vectorizer to guarantee that the memory regions pointed to by the various pointers do not overlap in the interaction spaces of the loops in which they are computed. As the C standard has evolved over time, support for the “restrict” keyword has been added, as can be seen in the example in Figure 7.

     void restrict_compute(restrict int *a, restrict int
     *b, restrict int *c)
     {
          for(int i=0; i<LIMIT; ++i)
               a[i] = b[i] * c[i];
     }

Figure 7: C Standard “restrict” keyword

By placing the restrict keyword qualifier on the pointers passed to the procedure, this ensures to the compiler that the data accessed by a given pointer with the restrict keyword does not alias with anything else the function may modify using another pointer. Note that this only applies to the function at hand, not the global scope of the application itself. This permits the data dependence analyzer to recognize that arrays are not aliased or modified by references with other side effects, and allows more aggressive optimization of the loop nest including vectorization amongst other optimizations.

Source:-http://www.embedded.com/design/debug-and-optimization/4436459/Achieving-better-embedded-software-performance-through-memory-layout-optimization-Part-2                        

Sensor Fusion Goes Open-Source

AUSTIN, Texas – Analog Devices, Freescale, PNI Sensor Corp., and the MEMS Industry Group formed the Accelerated Innovation Community, a group dedicated to providing open-source algorithms for sensors. AIC also plans to announce an I/O standard for sensors in collaboration with the MIPI Alliance.

Engineers shouldn't have "to reinvent the wheel on common algorithms every time they want to add or change functionality in their product," said Karen Lightman, executive director of the MEMS Industry Group (MIG). "Access to an open-source library of introductory algorithms fundamentally changes the development paradigm."

Freescale was an early catalyst of AIC and has added open-source algorithms such as a C source library for 3-, 6- and 9-axis sensor fusion. Sensor fusion is a basic building block for sensor data analytics and for motion tracking, said Freescale's Ian Chen.

"It's all about bringing the relevant data together from multiple sensors to provide a bigger picture of what's going on in a system," Steve Whalley, chief strategy officer at MIG and a former director of sensors at Intel, told EE Times. AIC aims to let engineers "focus their own real differentiating capabilities on the more complex algorithms that are needed for today's products above and beyond the introductory algorithms in the AIC."

Steve Whalley

The key challenge in sensor fusion is effectively separating signal, motion, and noise, Chen said. AIC's algorithms aim to take redundant data from different sensors that observe the same event to distinguish between noise and signals, then compute more accurate information.

"Sensor fusion encompasses a variety of techniques which leverage the inherent strengths and monitoring that these individual sensors do to achieve more accurate results than the individual components could achieve by themselves," Chen told EE Times.

Source:-http://www.eetimes.com/document.asp?doc_id=1324503&

Synopsys Simplifies Low Power Lot Sensor & Controller Soc Design

Synopsys, Inc. has just released a complete hardware and software IP building block optimized for a wide range of ultra-low power embedded sensor and control applications.


"Embedded sensor and control applications require a high level of integration with minimal power and area," said John Koeter, vice president of marketing for IP and Prototyping at Synopsys.

To achieve this goal, he said, the company's Sensor and Control IP Subsystem integrates the DesignWare ARC EM4, EM6, EM5D or EM7D 32-bit processors, delivering efficient real-time control and DSP performance required for ultra-low power sensor- and control-based applications.
Newly integrated peripherals include a UART for serial communication as well as a Pulse Width Modulation (PWM) block and Digital-to-Analog Converter (DAC) interface for actuator/motor control functions.

An optional IEEE 754-2008 compliant floating point unit (FPU) reduces energy consumption by up to 10X for sensor fusion applications implementing floating point operations. He said designers using the DesignWare building block are provided with a pre-verified, SoC-ready IP subsystem that delivers the energy- efficient processing required in markets such as the Internet of Things (IoT).
Koeter said the subsystem is designed to process data from digital and analog sensors and always-on audio sources with minimal power consumption. "This enables offloading of the host processor and more efficient processing of the data,

" he said.
The fully configurable subsystem includes the choice of an ARC EM4, EM6, EM5D or EM7D processor. All the processors support up to 2 MB of closely coupled memory (CCM) for both instruction and data, while the EM6 and EM7D also incorporate up to 32 KB of instruction and data cache for maximum system performance and flexibility.

The EM5D and EM7D provide developers with a high-efficiency control and signal processing capability that gives them access to more than 100 DSP instructions. Included in the subsystem are integrated UART, PWM and ARM AMBA APB interface peripherals combined with the configurable GPIO, SPI, I2C and ADC/DAC interfaces for a variety of off-chip sensor and actuator connections.

Targeted at designs where it is necessary to process the extensive amount of data in sensor fusion applications, the subsystem includes a rich library of off-the-shelf DSP functions supporting filtering, correlation, matrix/vector, decimation/ interpolation and complex math operations.

"Designers can implement these sensor-specific DSP functions in hardware using a combination of native DSP instructions within the EM5D or EM7D processor and tightly coupled hardware accelerators," said Koeter, "to boost performance efficiency and reduce power consumption by up to 85 percent compared to discrete solutions. "

An optional IEEE 754-2008 compliant FPU reduces energy consumption by up to 10X for sensor applications requiring single- or double-precision floating point operations. Additionally, the ARC Processor EXtension (APEX) technology enables designers to add their own user-defined instructions or existing hardware to the processor. 

ICS-CERT warns BlackEnergy malware attacking SCADA system HMI

The US Department of Homeland Security's Industrial Control System Cyber Emergency Response Team (ICS-CERT) has just issued an alert about malware that is targeting human-machine interfaces (HMIs) of industrial control systems. https://ics-cert.us-cert.gov/alerts/ICS-ALERT-14-281-01A.


It is based on a varient BlackEnergy malware toolkit malware that infects HMIs on any supervisory control and data acquisition system (SCADA) that has a direct connection to the Internet. It is a continuation of a malware campaign targeting numerous companies that has been ongoing since 2012.

In applications where an ability to remotely monitor or operate the system is required, the SCADA/HMI is often connected to the public Internet as the link to the remote operator. It is such installations that the BlackEnergy malware has been attacking the alert warns.

So far, the report lists three commercial SCADA/HMI software products are listed in ICS-ALERT-14- 281-01A, including GE Cimplicity, Advantech/Broadwin WebAccess, and Siemens WinCC for SIMATIC.

The ICS-CERT analysis indicates the attack involves making an HMI server run a malicious screen file hosted on an attacker-controlled server, which then installs the malware. According to the alert "at this time, ICS-CERT has not identified any attempts to damage, modify, or otherwise disrupt the victim systems’ control processes."

Howver, ICS-CERT warns that this kind of malware usually searches for removable media and network-connected file shares that can provide a pathway into the target company's computer networks.

Source:http://www.embedded.com/electronics-news/4436970/ICS-CERT-warns-BlackEnergy-malware-attacking-SCADA-system-HMIs

3/6 Months Industrial Training | Summer Training | Winter Training Course

101% Placements Assistance

Description for "PLC SCADA & EMBEDDED SYSTEM TRAINING"

Winter Training with Placement on Embedded System, Advanced Embedded System, C Language, Industrial Automation, PLC, SCADA, VHDL, Verilog HDL,  IBAS, MATLAB,.NET, J2EE, @SOFCON Noida, Delhi, Ghaziabad, Lucknow, Jaipur, Bhopal, Ahmedabad, Baroda, Rajkot.

SOFCON, an Indian Multinational, ISO 9001:2008 Certified Company is a renowned name among Engineering Students, Working professionals and MCA/BCA professionals for providing quality education in the forms of summer, Industrial & Winter Training. SOFCON has formed a group of enthusiastic and well competent professionals, having a unique training methodology which makes SOFCON Northern India No-1 Training Company with a bright history of training more than 50,000 engineers and professionals.

Today almost every Engineering & Professional graduate programs in India include Industrial/Summer/Winter/Project Training as an important part of their curriculum, with an objective to enhance the knowledge of the students on different cutting edge technologies which has been important part of respective industry but most of the students always run to obtain a merely certificate and due to this there is serious lack of trained professionals with the desired skill sets to take on the ever increasing demand of an industry.

In order to eradicate this deficiency and creates skilled resources for the challenging industry, SOFCON has designed a curriculum for Winter/Project/Industrial training which incorporates a blending learning approach by integrating classroom, hands on lab exercise and team projects to provides students both the theoretical & practical training, needed to build strong technical skills.

Eligibility B.Tech./B.E./MCA/B.Sc.(IT)/Diploma or equivalent in any stream.

Training Location: Noida, Delhi, Ghaziabad, Lucknow, Jaipur, Bhopal, Ahmedabad, Baroda & Rajkot.

Course Duration: 2 weeks, 4 weeks, 6 weeks, 3 months, 4 months & 6 months.

Date of Starting: Different batches are starting in every 10 days gap from December to April (Please

Technologies Offers From SOFCON:

 Embedded System
 Advanced Embedded System
 Industrial Automation [PLC, SCADA, Drives, HMI, Motion Control]
 VLSI [VHDL, Verilog HDL]
 IBAS [Industrial Building Automation System]
 MATLAB
 .NET
 J2EE

Why SOFCON

• SOFCON is a group of 3 company not only a training institute

• More than 18 years of Experience in Technology Training 

 
• A Competent group of 780 dedicated & highly skilled employees as well as industrial experience with 200+ in house Trainers

• Bright history of Training more than 50,000+ Students and Professional so far

• 12+ Training Locations across the globe with all required modern facilities

• Courses mapped with Industry Requirement in order to ensure 100% placement for our students

• 12,000+ Engineer Placed by SOFCON across Industry

• Strategic tie-ups with Global Technology leaders in order ensure quality training for our students, as well as placements

• On site practical exposure

• Intensive skill development.

Special Features of Training:

• Opportunity to participate in campus placement of top companies.
• A Discount of Rs. 500/- for the students who will join two programs.
• Advance & Updated Kits and Components provided to each students for practical purpose
• We have using Development Board which is design by SOFCON Engineer
• We have using our own SOFTWARE for training purpose
• Specially designed Learning kit containing a book and a CD would be provided free of cost to the students of all courses.
• SOFCON student Membership of $20 is free of cost.
• Certification by SOFCON India Pvt. Ltd. (Subjected to at least 70% Attendance).

Training Programs at your college campus: SOFCON can deliver a free of cost technical seminar at your campus for training at your college campus. After the seminar, if at least 40 students are interested to join the training, then same program may be conducted at your campus. 

 This training program may be conducted at any time whole of the year at your campus.
Other SOFCON Programs: 6 Months Projects based training for B.Tech./MCA Students. Regular training programs whole of the year at all of our campuses as well as at the college campuses. Summer training programs in the month of May, June, July & August for 2/4/6 Weeks.

SOFCON Profile: Sofcon Group has over 02 decades of rich experience in providing turnkey automation solutions to applications like Cement Plants, Power Plants, Food Processing Plant, Chemical Process Automation, Plastic, Pharma Machineries, Oil Refineries, Water Treatment Plants, DG Automation, Energy Monitoring, Load Management, Material Handling, Coal Plant, SCADA Systems, Aluminum, Picture Tube, Automobile, Ash Handling etc.

Sofcon India Pvt Ltd (ISO 9001-2008 & IAO-International Accreditation
Organization Accredited)
We impart hands-on training on Industrial Automation, Embedded Systems & Integrated Building Automation System (IBAS) to II/III/Final/Passed Engineering Graduates/Diploma, Working Professionals & Technicians. We have trained more than 30000 Engineers, Technicians and Working Professionals, we have 11 No fully equipped training centers in India at Noida, Delhi, Gurgaon, Ghaziabad, Jaipur, Lucknow, Bhopal, Ahmadabad, Baroda and Rajkot.

In-Campus Training at Colleges:

We have conducted more than 250 in-campus college batches. A few colleges are BIET Pilani, DAV Jalandhar, Gyan Ganga Jabalpur, BVMCTM Gwalior, HCST Mathura, Subharti Meerut, RGEC Meerut, Arni University HP, SMEC Neemrana, GITS Udaipur, NRI-IST Bhopal, SIET Allahabad, BSA Mathura, Ideal Ghaziabad, CIT Vodakara, NIEC Delhi, LKCT Indore, EIT Faridabad, ITM Gwalior, PCTE Ludhiana, DCTM Palwal, Sunrise Lucknow, RPS Balana, SIRT Bhopal, KNIT Sultanpur, MVN University Palwal, GIET Gunupur, BIET Lucknow, HCST Mathura, Vidya College of Engg Meerut, AITS Udaipur, RPS Balana Mohindergarh, Techno India NJR IET Udaipur, CSIT Durg, SAM College Allahabad etc. (A few testimonials attached).

In-Plant/Corporate Training:

We customize the training needs of various corporate in India and abroad as per plant/facility requirements. We have successfully conducted more than 150 customized training programs. A few names include Indraprastha Gas, GlaxosmithKline, KS oils, Ultratech Cement, Bajaj Auto, Schenk Rotek, McCain Foods, Moser Baer, JCT Electronics, CCIL, JP Group, IDMC Ltd., Parle Biscuits Ltd, IRPPL, Tudor India Ltd., Shree Cements Ltd, Emersion Ltd., Case Construction Ltd, Sergi India, Ecocat Pvt Ltd, Pepsico, JHOC Yemen, Qatar Petroleum, NHPC, Ingersoll Rand, Pepsico Kolkata, Samsung India Electronics etc. (A few testimonials enclosed).

Live Projects: The participants who are interested to work on live projects can work on the specialized live projects. These live projects will be offered by SOFCON India Pvt. Ltd. and participants have to complete these projects in given time frame. This time frame may be 6 months or one year. Incentives may also be given to the candidates, depending upon their performance while handling the live projects. The groups for working on live projects will be decided by students.
Testimonials:

"We had conducted Campus Recruitment Preparation Program with SOFCON at our campus. From the initial contacts to the conclusion of the course, we have found SOFCON to be very professional and helpful in all aspects. We look forward to conduct other training programs in coming years."
Mr. Amandeep Singh -Head Continuing Education Department IIT-Delhi

"The Training provided by SOFCON is of a very high caliber. The staffs are highly skilled and flexible, making training a worth. We will continue to take SOFCON Services in the future and would have no hesitation in recommending them to other Institutions."
Mr.Prateek Mishra-Honda Car Ltd. – Greater Noida

"In SOFCON I learnt the magic of Coding .The constant and personal interaction with the trainer is the best part of SOFCON. I thank SOFCON for making my most cherished dream come true."
Mr. Piyush Sharma- SAMSUNG India Ltd.

"I joined SOFCON because of their proven expertise in training budding engineers and professionals. Their ability to understand our problems and giving us the optimal solution is something, we have grown to expect from SOFCON"
Mr. Kapil Shukla- Bhushan Steel - Ghaziabad