Driven by the need to balance various power, performance, and cost trade-offs, microcontroller clock systems are increasing in complexity. By analyzing critical aspects of clock system design, including load capacitance, system reliability, and energy consumption, designers can determine how best to meet the requirements of low-power microcontroller applications.

Today, the range of applications for microcontrollers (MCUs) is vast. While these ubiquitous computing engines advance in processing capabilities, peripheral offerings, and more efficient power consumption, the number of applications continues to increase at incredible rates.

As application requirements have expanded, so have key system components that reside on the microcontroller, one of which is the clock system. This system plays a critical role in a microcontroller and is vital to various aspects of overall system performance, including optimized power dissipation, accurate time keeping, communication interface clocking, and internal clocking requirements for other key components within the microcontroller.

Resources and requirements

The clock system can be considered a pool of resources, called clock resources (see Figure 1). Each clock resource is optimized for a primary purpose even though it can be used for various functions within the system. The clock system typically includes various clock sources, called system clocks. These system clocks are used to control various subsystem components such as the CPU, bus interfaces, peripherals, and data converters. Because application requirements can vary considerably, each system clock offers several clock resources.

Given that a general-purpose MCU can be used in hundreds if not thousands of applications, the clock system must be highly programmable. This allows the clock system to be reconfigured as needed in a specific application. Some simple applications require only a static configuration, and the clock system is configured only once during initialization. Others require a dynamic configuration that allows the clock system to be reconfigured based on the application’s real-time behavior.

The types of clock resources available in the clock system are important. Applications have different demands needed to implement a particular function. For example, real-time clock systems require an accurate time base for keeping time over the application’s lifespan. Most clock systems have an integrated oscillator that supports the most common watch crystal available, 32,768 Hz. External crystals require the proper load capacitance to center the frequency properly and optimize start-up.

To reduce system cost, some microcontrollers integrate programmable load capacitors that allow for a range of capacitance values to support the most common crystal load requirements. Some systems already have a real-time clock resource available. For these systems, a bypass mode can allow this resource to be shared with the microcontroller. In a similar fashion, the microcontroller clock system can output a buffered real-time clock source to be used elsewhere in the system when required.

Microcontroller frequency range has increased dramatically in the past several years. Processing requirements have driven this expanded frequency range as software complexity levels have increased. Most MCUs have various methods for generating the high-speed clocks required in the system, most commonly with an embedded oscillator that requires no external components. This saves component cost and, more importantly, reduces the microcontroller’s pin requirements. The oscillator is typically designed to have good start-up times, as well as fairly tight tolerances on the order of 1 to 3 percent over voltage and temperature.

Finding faults and preventing errors

One critical aspect of the clock system is the reliability of system clocks, especially the processor clock. Ideally, the processor clock should be readily available at all times to ensure the application can recover from a system error that can lead to a deadlock situation. Because the clock system is highly programmable, it poses some risks by incorrect or inadvertent programming if code execution goes astray.

Most clock systems have password-protected access to all the critical clock system configuration registers. This minimizes the chances of an inadvertent configuration due to errant code execution. In addition, a good clock system should have other hardware mechanisms to prevent a deadlock situation.

A good example of this is proper fail-safe mechanisms for all crystal resources. External crystals or resonators can fail due to board wear, electrostatic discharge events, weak solder joints, and other reasons. If the processor system clock uses a crystal for its resource and it fails, this could cause clock loss, and a deadlock situation could occur.

To prevent this, most microcontrollers have hardware mechanisms that check if the crystal is operating correctly. Checks include non-oscillation or perhaps oscillation at the improper frequency range. Regardless, if a fault is detected, the system clock is automatically switched to a known, good clock resource, allowing the application code to continue to execute. Furthermore, an error condition is reported to the application, such as a non-maskable interrupt or a reset condition where the application can determine which action to take. This known, good clock source is often a fully embedded oscillator that is robust in terms of start-up characteristics and oscillation reliability.

Improving energy efficiency

Most MCU applications demand low or ultra low power. Because many applications use limited energy sources such as small, low-capacity batteries, product longevity depends on efficient energy usage. The best way to conserve energy is to use the proper amount of energy required at a given time and reduce all energy consumption to a minimum at all other times. This is the classic duty-cycle profile. In general, most vendors call this active time versus sleep or standby time. The longer the device can remain in sleep time, the less energy will be consumed overall.

Clock system design is critical to minimize energy requirements during sleep or standby operation. Most standby or sleep modes are characterized by the use of low-frequency clocks. Several options can provide this low-frequency clock operation.

The watch crystal is one such resource. It has a nominal 32 kHz operation, is very precise, and can be designed to operate at very low current consumption on the order of 500 nA or less depending on the crystal type. This is a good option if a watch crystal is already in the system, so no additional cost is incurred. If a crystal is not required, an embedded oscillator is another valid option that can be extremely low power, some as low as 100 nA.

These oscillators typically involve a trade-off in power versus accuracy. Higher accuracy often requires dissipating higher power. The oscillator is affected by temperature and voltage changes that could be important in some applications. Therefore, many microcontrollers have various clock resources for this purpose, some with higher power requirements yet improved accuracy or drift characteristics. These oscillators are robust and low cost and require no external components or pins.

Another important aspect of the clock system that can significantly reduce power is the clock distribution logic, which entails how the various clock systems are routed or distributed inside the MCU. Because clocking is a key factor in dynamic power consumption, it is critical that the clock distribution logic is completed in such a way to minimize unnecessary clock loading and clock switching. All system clocks should be gated off or held static when not required. In addition, only logic that requires a particular system clock should be seen as loads to that respective clock.

Many microcontrollers divide a particular system clock into several individual clocks, which only feed a specific module or peripheral. When a particular module needs the system clock, it will send a request and only the module that has requested the clock receives it, dramatically reducing overall dynamic power.

Flexible design for diverse applications

Many aspects are involved in designing a clock system for microcontrollers. The MSP430 5xx/6xx series of microcontrollers from Texas Instruments Incorporated (TI) contains many of the necessary components described previously. These MCUs support low-frequency watch crystal operation, as well as a broad range of high-frequency crystals. Both crystals have fail-safe logic and can be used in bypass mode. The clock system also contains an embedded oscillator with a Frequency-Locked Loop (FLL) for high-frequency operation with no external components. The FLL allows for any multiple of the low-frequency clock as its reference, providing flexibility in frequency selection.

An extremely low-power embedded oscillator of less than 100 nA is available for low-power, non-accurate, crystal-less clocking applications. A more accurate low-power embedded oscillator is also available for more stringent clocking needs. Furthermore, sophisticated clock distribution logic is offered with a highly flexible clock request system. All of these aspects of the clock system allow TI’s MSP430 5xx/6xx series of microcontrollers to serve a broad range of diverse microcontroller applications in a low-power, cost-effective manner.

Craig Greenberg is a systems developer in the MCU Division at Texas Instruments.

Texas Instruments Incorporated 972-995-2011 www.fb.com/texasinstruments https://plus.google.com/#104292131839044508100/posts @TXInstruments www.ti.com

Part 2 in a 2-part series: Embedded systems migrating to 40G today and 100G in the next few years demand an intelligent in-line preprocessor capable of handling traffic at this high line rate, while communicating with the x86 CPU subsystem over a high-performance, virtualized PCI Express interface. Part 1 in this series examined the challenges of processing network traffic at 100G and some of the commercially available solutions attempting to solve such challenges. Part 2 highlights the need for a coprocessor that is tightly coupled to a multicore x86 CPU and can manage functions such as intelligent L2/L3 switching, flow classification, in-line security processing, virtualization, and load balancing for x86 CPU cores and virtual machines.

To keep pace with the explosion of traffic in the enterprise and carrier network, embedded designers have tried a variety of methods to meet the demand for 100G secure communication, including embedding hardware accelerators into multicore[] processors or using devices such as network processors, Ethernet switches, or Ethernet controllers. These approaches each come with their own drawbacks that limit performance and increase complexity. Furthermore, attempts to use a single-chip heterogeneous multicore processor to bypass performance issues have led to proprietary architectures that are not operating system friendly.

A high-performance multicore heterogeneous architecture builds on a single-chip multicore heterogeneous processor, but divides the solution into two processors: a general-purpose multicore x86 CPU focused on application and control plane processing and a separate in-line multicore coprocessor focused on L2-L4 processing and accelerating L4-L7 applications. The key to this architecture is having a tightly coupled interface between the two processors that is in-line, secure, virtualized, and high-performance (see Figure 1). A good analogy here is the use of a graphics processor unit alongside a multicore x86 processor in workstations and other graphics-intensive servers.

Efficient processing and memory utilization

The coprocessor needs to access packets, forwarding the packet and its associated metadata (packet state) in a timely manner with minimal latencies. This dictates having hierarchical memory architecture of on- and off-chip memories, with packet data effectively managed through the hierarchy. For example, first-level lookup tables can be in on-chip memories, while large volumes of data can be stored in external memory tables.

In addition, the use of multiple threads per processing core can bypass the memory wall problem. A core or thread continues to execute until an external memory access is needed, at which point another processing thread takes over. The resulting asynchronous memory architecture decouples external memory accesses from processing, maximizing overall system performance. This allows for bulk memory transactions, where many memory accesses are pooled together into one memory transaction, further increasing the efficiency of the external memory interface.

In-line or look-aside processing with security and virtualization[]

The coprocessor is in-line with ingress and egress traffic and should be able to, on-the-fly, encrypt and decrypt the packets, classify packets into flows, and look up the flow state table to determine the action needed on the flow. The coprocessor also implements I/O virtualization, allowing the x86 cores and their Virtual Machines (VMs) to share the I/O subsystem. In addition, the coprocessor should be able to dynamically load balance the traffic to the x86 cores and VMs based on flows.

Fast interconnect with x86

Supporting a heterogeneous processing architecture requires a high-performance interconnect to the x86 processor with I/O virtualization capability. For example, an 8-lane PCI Express Gen 2 interface supports up to 40 Gbaud of traffic to an x86 CPU socket. (Note: Overhead on read and write cycles brings this number down to the low 20s.)

Cut through/intra-flow cut through

Ideally, not all flows need to be transmitted to the x86 processor, as the coprocessor is intelligent enough to classify packets into flows. Based on the flow state table, an action can be taken to cut through, drop, or forward to x86. In some cases, the first few packets of a flow are forwarded to the x86 subsystem for inspection. The x86 processor can then instruct the underlying coprocessor to cut through the remainder of the packets in the same flow.

Inter-VM switching

The advent of VMs and the need for I/O virtualization have created a new set of requirements that mandates a more intelligent approach for managing I/O. This has prompted the need for an intelligent way to interconnect VMs on different cores to handle the so-called east-west traffic. Such VMs can belong to different tiers of servers in the data center. Having the VM-aware switch on the coprocessor can achieve the VM interconnect.

Passive NIC mode

The coprocessor should be able to support a mode where all network I/O traffic is passed to the x86 processor. This mode is required for monitoring and statistics or for applications requiring 100 percent of x86 CPU processing.

Implementing the OpenFlow protocol

Software-Defined Networking (SDN) allows users to bring the benefits of virtualization – including shared resources, user customization, and fast adaptation – to the switched network by defining traffic flows and deciding how these flows are treated in the network. In other words, it allows the system user to remotely control the network hardware with software in a dynamic and programmable fashion.

SDN puts the intelligence of the network into a hierarchy of controllers. In this hierarchy, switching paths are centrally calculated based on IT-defined parameters and then downloaded to the distributed switching architecture. A hardware-agnostic architecture that uses standard open interfaces to the hardware can change the way we build networking systems today.

The new OpenFlow protocol supports SDN. An OpenFlow controller typically runs on a multicore x86 processor and implements the control plane protocols. It downloads the state information onto multiple flow state tables in the coprocessor, implementing the data-switching plane through a standard OpenFlow API. The coprocessor, being a stateful flow processor, can be optimized to support the OpenFlow architecture.

Best of breeds for the future

As line speeds continue to grow, it remains to be seen how application workloads will be divided among x86 general-purpose multicore CPUs and external supporting coprocessors. The flexibility of riding a product roadmap for multicore x86 processors separate from that of coprocessors gives designers the choice to use the best of breeds in trying to meet ever-increasing future challenges.

Editor’s note: Read Part 1 in this series online at http://embedded-computing.com/managing-processors-40100g-part-of-2.

Nabil G. Damouny is senior director of strategic marketing at Netronome.

Netronome 408-496-0022 info@netronome.com @netronome www.netronome.com

As more and more embedded devices evolve from single-function controllers to complex platforms supporting high-speed graphics, user interfaces, and network communications in addition to the primary application, real-time responsiveness is becoming a critical performance requirement. Although developing in-house software offers some advantages, the benefits of reduced complexity and shorter development schedules often justify the purchase of a commercial Real-Time Operating System.

The average person interacts with hundreds of embedded processors every day in phones, automobiles, home appliances, toys, cash registers, entertainment electronics, security systems, environmental controls, and personal electronics. The common link among all of these products is their ability to react in real time to the user, external events, and the communications channel.

The software for these embedded devices can be divided into application software and Operating System (OS) software. Application software makes the product unique and contains the data collection, signal processing, and hardware control routines required to make the product perform to its specification. The OS allows the programmer to break up large application programs into smaller, individually developed processes or tasks.

At the heart of an OS is the kernel, which schedules programs for execution and manages shared resources. A Real-Time OS (RTOS) processes hardware requests or interrupts from timers or external events within a guaranteed maximum time. Programmers interact with the OS through an API and set up the priorities and data dependencies. During execution, the RTOS manages the application software with a flurry of external real-time activity.

In-house code

Even with the advantages of an RTOS, homegrown OSs still occupy a non-trivial percentage of embedded real-time products. Developers have multiple incentives for bypassing a commercial RTOS entirely and writing their own real-time routines. The biggest reason developers cite for not choosing a commercial OS is lack of need. With only one task running, designers think they can easily keep track of the required hardware interaction.

Special situations sometimes justify in-house software. For example, the design objectives of a portable health care device can include low cost, low power, and a one-year battery standby life without extra memory and processing power to support a commercial RTOS. Furthermore, if a new project is an upgrade of a previous project, developers likely will want to use as much legacy code as possible.

Components that aren’t invented at the same company might also be one reason why many developers write their own OSs. Installing software from a third party into their showpiece product is like admitting they are somehow not up to the task. In addition, developers might think they’ll lose the ability to make software adjustments to compensate for hardware changes or to correct bugs. The designer can easily adjust the order of execution or drop to assembly language to solve critical timing problems with in-house developed software. However, with a commercial RTOS, the scheduler handles many of the timing issues, so developers lose the perception of being in total control. And finally, programmers list sticker shock as another reason to write their own operating software. The initial license for a full commercial RTOS and associated tools can be in the $15,000 to $20,000 range for a single development seat, plus recurring royalties for every unit shipped.

Software shortcuts

As embedded systems grow in complexity and project schedules shrink, software has displaced hardware as the highest-priced item in most embedded development projects. If design teams can buy an RTOS and eliminate the coding, debug, and documentation of the most complicated portion of the software structure, then the purchase decision should receive careful consideration. Although a commercial RTOS can be expensive, a smaller development team and shorter project time frame might create more than enough savings to justify the purchase.

An RTOS allows programmers to write independent, reusable modules to reduce software complexity and shorten the development schedule. Programmers can write each software routine independently without getting bogged down with intertask timing problems. Most RTOS vendors provide a full interactive development environment including a source code editor, code manager, linker, downloader, runtime tools, and one or more debuggers. Software vendors also supply software performance analysis tools to help profile and visualize real-time activity in application routines. Programmers can monitor which tasks are running, observe the stream of data flow, and detect when and how often a task is interrupted by a higher-priority item. RTOS vendors agree that high-quality development tools can dramatically shorten debug time.

Along with the cost savings, RTOS vendors cite multiple technical reasons to justify their products. For example, if an application involves heavy data processing, many RTOSs can be scaled easily to spread tasks across several processors for a significant performance boost. The RTOS provides communication and synchronization services to make multiprocessing transparent. In addition, an off-the-shelf RTOS working alongside multicore[] processors simplifies legacy code integration within new designs or products updates.

A commercial RTOS is modular, so users can select only those portions or features of the OS that they need. Specifying a subset of the full-blown commercial RTOS can reduce acquisition costs and the required memory footprint. With the current connectivity trend, even the simplest embedded products might need to connect to and send data over the Internet. A graphical user interface could also become standard in small embedded systems, even if just for maintenance. These features are included or optionally available in most commercial RTOSs, but can be very expensive or impossible to add to a proprietary OS. Vendors also promote product on-demand technical support as a major benefit of a commercial RTOS.

Off-the-shelf platforms

Commercial RTOSs are constantly upgraded to add new features and keep up with changing technology. For example, the popular VxWorks OS from Wind River was recently revised to deliver 64-bit computing support along with improved multicore features. VxWorks includes a shell, debugging functions, memory management, performance monitoring, and support for multiprocessing. Real-time features include a kernel for preemptive multitasking, interrupt response, interprocess communication, and a file system (see block diagram in Figure 1). Software development is enabled by the Wind River Workbench development tools suite and Intel Integrated Performance Primitives for VxWorks.

The RTOS supports various multicore configurations in Symmetrical Multi-Processing (SMP) and Asymmetrical Multi-Processing (AMP) modes or as a guest OS on top of Wind River Hypervisor. VxWorks also has a configurable and tunable small memory footprint, allowing the user to control how much of the OS to employ for each project.

In addition to offering a multitude of commercial RTOS products, the embedded systems community maintains an open-source OS based on a real-time kernel that is free for use in commercial applications. The FreeRTOS Project is under continuous active development and is distributed under the GNU General Public License with an optional exception that allows users to keep their proprietary software confidential. Free source code and the lack of recurring royalties are popular features for small, low-budget embedded projects. FreeRTOS has been ported to multiple microcontroller platforms and has minimal ROM, RAM, and processing overhead, resulting in a typical kernel binary image in the 4 KB to 9 KB range. Although FreeRTOS source code for the kernel is contained in only three C code files, the zip file download includes numerous demonstration applications to help new users get started.

The biggest complaint among potential open-source software users is the lack of a central resource to provide support similar to that offered by a commercial software vendor; however, the FreeRTOS website has an active free support forum where developers can find answers to their technical questions. In support of the open-source platform, Microchip Technology offers the FreeRTOS Microchip PIC32 Education Kit (see Figure 2). This $95 kit includes a development board that enables users to develop USB embedded host, device, and On-The-Go applications on the PIC32 microcontroller family.

Real-time future

Although programmers might get excited when considering the challenge of developing an in-house OS, the “roll your own” days might be fading away. Designers can look forward to real-time software as the norm in future embedded products.

Customer demand for faster response times, complex functionality, and instant data access continues to increase the challenge of embedded design. Advancing technology also dictates that embedded products be capable of periodic software updates as requirements change, along with the possible transfer to the next-generation hardware platform.

Developers should take the time to analyze their system requirements, development schedule, software support, expandability, communications, scalability, and future growth before embarking on an in-house software development project. An off-the-shelf commercial RTOS or even an open-source operating system could be in your future.

By using intelligent motor management modules, plant managers can ensure that electric motors operate reliably and efficiently. These devices not only prevent costly downtime, but can also monitor energy usage and help lower utility bills.

Today’s critical manufacturing operations that involve components such as control valves, pumps, fans, heaters, or conveyor systems rely on fast and precise switching. Upon start-up, the electric motors used in these applications can draw up to 6x the full load current used during normal operation. The larger the motor is, the more inrush or demand it places on the electric utility’s distribution system when it starts.

In addition to kilowatt-hour (kWh) meters that measure total energy consumption, utilities typically use a demand meter to measure a commercial customer’s power usage rate.

Power factor is the ratio of the real power flowing to the load over the apparent power in the circuit and is usually expressed as a decimal between 0 and 1.0. The ideal power factor is 1.0 or “Unity.” When a commercial customer’s power factor goes below 0.95, utilities often add a surcharge to the customer’s bill. The meters are most affected by the large inrush currents that electric motors draw when they start. Consequently, motor loads are a prime cause of inductive or lagging power factors.

Most plants have numerous motors in place. If all of these motors started simultaneously, an enormous amount of energy would be demanded upon start-up. To prevent this excessive energy draw, most plants use a sequential motor start-up process.

During a manufacturing process, the cycling of start-ups and stops can be random. Eventually, however, it is possible that two or more large horsepower motors will start at or very near the same time. When that happens, the large inrush currents will increase and draw more energy demand. This can lead to higher energy expenses for that month, even if that level only existed for a moment.

Other problems that can lead to increased current draw include:

• Clogged filters in a pump application
• Excessive product loading on conveyors
• A mechanical bearing starting to seize due to contamination, wear, or end-of-life condition

These issues can exist for long periods of time without stopping the motor or alerting the plant manager that there is a problem. This can lead to significant energy waste, decreased efficiency, and higher utility costs, all without the utility customer’s knowledge.

Measuring current

When analyzing the motor load’s physical variables, the motor current I for low and medium loads hardly changes. The magnetic saturation makes this effect especially noticeable for small horsepower motors. The current only significantly increases in the maximum load range. Classic motor-protection relays and motor-protection circuit breakers use current-dependent bimetallic, eutectic alloy, or solid-state overload relays to evaluate this range. This means that they can protect the drive motor from an overload condition once sufficient current has passed through them.

The curve of power factor cos φ manifests an almost opposite characteristic, changing the most in the motor’s lower load range. The power factor only marginally changes if the motor power increases. With this characteristic, power factor cos φ is suited to detect load changes when the motor is close to no-load operation, and in turn, protects drive elements against underload conditions. Both the power factor and the motor current are significantly influenced by voltage fluctuations, which can cause them to supply inaccurate values.

In practice, most applications use electric motors with more capacity than necessary. These oversized motors offer a few advantages, including longer lifespan for the motor bearings, a power reserve, and a smaller replacement motor inventory. However, these motors present a significant disadvantage. Because the motor has a lower load, it does not use its full load range. Major changes in the motor current no longer lie in the typical load range, so overload protection is inefficient and more difficult to detect.

Independent of this effect, evaluation of standard overload relay response is not effective when it comes to protecting plants and systems given that they respond slowly when the current increases. This is because an overload relay must permit normal start-up of an electric motor with an inrush current of between 5x and 7x the rated current.

For 7x the rated current, a Class 10 trip curve with a comparatively fast tripping characteristic requires approximately nine seconds before it trips the motor. The extent of damage to the connected mechanical system can range from increased wear to complete destruction, depending on the particular application and system involved. To protect more sensitive systems, a faster response speed than normally expected from an overload relay is absolutely critical.

Electronic motor management

Using an electronic motor management module in conjunction with a Programmable Logic Controller (PLC) is one solution to this problem. The energy-monitoring device senses the motor current and then communicates with the PLC to prevent two or more motors from starting simultaneously. This minimizes energy demand and can significantly reduce the plant’s energy bill.

Electronic motor management modules constantly monitor three currents, voltages, and phase angles every 6.6 milliseconds to determine a motor-driven system’s actual power consumption. An entire system, which includes a motor driving a specific load (pumps, actuating drives, fans, and machine tools), can be monitored for proper functioning, contamination, and wear.

The modules can measure currents up to 16 A via integrated internal current transformers. Other modules can measure much higher currents through external current transformers. Note that the module itself does not actually perform the load switching; rather, it controls any contactor rated for that particular motor load.

These devices can detect electric current usage through inputs from onboard or external current transformers. By programming alarm thresholds, users can minimize or eliminate downtime. The module can signal an alert that a process motor is drawing excessive current, which could lead to an overload condition. Fast response is necessary to protect a system’s operations. This advance knowledge helps prevent downtime.

An electronic motor management module such as Phoenix Contact’s CONTACTRON motor manager uses the power curve’s linear trend to detect critical load states. Only active power (P) has an almost linear characteristic that is independent of the motor load. The calculation formula already includes the voltage influence, so it is not considered an external disturbance variable.

With its linear characteristic, active power reliably detects all load states and infers motor torque, allowing the module to reveal overloads, underloads, and all critical states. Figure 1 demonstrates two such cases in a pump application.

Using a motor manager that is completely programmable is especially valuable in this situation. The programmable warnings allow fast response times when the loads reach critical levels.

Monitoring the power factor

Some motor management devices can be used in stand-alone applications as part of an energy data acquisition center. The plant manager can keep track of energy consumption data to ensure that the system is energy efficient.

For example, the module could be programmed with a day counter limit of 20 kWh (see Figure 2). When the power usage reaches that level, an output will send a warning to alert the plant manager.

A configurable electronic motor management module thus improves motor reliability by making it easy to query the motor’s load levels and analyze the active power curves of the different levels. Ultimately, this not only prevents costly downtime, but also helps the plant decrease its energy bill.

Mark Buckley is a lead product marketing specialist at Phoenix Contact.

Greg Dixson is director of industrial electronics at Phoenix Contact.

Phoenix Contact 717-944-1300 info@phoenixcon.com www.facebook.com/phoenixcontactusa www.linkedin.com/company/phoenix-contact-usa @PhoenixContact www.phoenixcontact.com