Month: November 2013

Over the last few years a number of automation vendors have announced various services including outsourced maintenance, system integration, manufacturing and business process consulting, and remote operations. I wonder if an automation vendor can continue to be effective as both a product company and services provider.

To clarify the difference, let’s start by defining what I mean by services and products. By providing services, automation vendors engage with customers to perform labor and knowledge intensive tasks that may include system design, engineering services, system integration, preventative maintenance, remote operations, and other services. By providing products, automation vendors sell something to the customers, system integrators and engineering firms that they will apply to accomplish automation tasks in manufacturing and process environments.

Service Dynamics

The primary objective of a service company should be to focus on the development a system solution that is uniquely suited to the idiosyncrasies of the client’s business without being tethered by particular product solution offerings. A big part of this is the ability to deploy technologies from appropriate sources using integration and engineering skills to achieve a superior result for the client. Service businesses need to have effective and refined project, personnel, and quality management systems. The growth and effectiveness of these businesses is directly related to adding and managing smart people and this is a unique business proficiency mastered by successful service organizations. Pure service businesses have an advantage of successfully maintaining alliances with a range of product vendors that cannot be logically achieved by product vendors who provide services. This separation positions a pure service business to use best of breed and get the most out of vendors. For comparison, consider you are a smartphone user and the only place to get apps was your phone hardware vendor.

refer to:http://www.automation.com/portals/factory-discrete-automation/can-automation-vendors-serve-two-masters-products-services

acrosser Technology Co. Ltd, a world-leading industrial and Embedded Computer
designer and manufacturer, announces the new AES-HM76Z1FL embedded system. AES-
HM76Z1FL, Acrosser’s latest industrial endeavor, is surely a FIT under multiple
circumstances. Innovation can be seen in the new ultra slim fanless design, and
its Intel core i CPU can surely cater for those seeking for high performance.
Therefore, these 3 stunning elements can be condensed as “F.I.T. Technology.”
(Fanless, Intel core i, ultra Thin)

The heat sink from the fanless design provides AES-HM76Z1FL with great thermal
performance, as well as increases the efficiency of usable space. The fanless
design provides dustproof protection, and saving the product itself from fan
malfunction. AES-HM76Z1FL has thin client dimensions, with a height of only 20
millimeters (272 mm x183 mm x 20 mm). This differs from most embedded
appliances, which have a height of more than 50 millimeters.

The AES-HM76Z1FL embedded system uses the latest technology in scalable Intel
Celeron and 3rd generation Core i7/i3 processors with a HM76 chipset. It
features graphics via VGA and HDMI, DDR3 SO-DIMM support, complete I/O such as 4
x COM ports, 3 x USB3.0 ports, 8 x GPI and 8 x GPO, and storage via SATA III and
Compact Flash. The AES-HM76Z1FL also supports communication by 2 x RJ-45 gigabit
Ethernet ports, 1 x SIM slot, and 1 x MinPCIe expansion socket for a 3.5G or
WiFi module.

Different from most industrial products that focus on application in one
specific industry, the AES-HM76Z1FL provides solutions for various applications
through the complete I/O interfaces. Applications of the AES-HM76Z1FL include:
embedded system solutions, control systems, digital signage, POS, Kiosk, ATM,
banking, home automation, and so on. It can support industrial automation and
commercial bases under multiple circumstances.

Key features:
‧Fanless and ultra slim design
‧Support Intel Ivy Bridge CPU with HM76 chipset
‧2 x DDR3 SO-DIMM, up to 16GB
‧Support SATA III and CF storage
‧HDMI/VGA/USB/Audio/GPIO output interface
‧Serial ports by RS-232 and RS-422/485
‧2 x GbE, 1 x SIM, and 1 x MiniPCIe(for3G/WiFi)

Product Information:
http://www.acrosser.com/Products/Embedded-Computer/Fanless-Embedded-Systems/AES-HM76Z1FL/Intel-Core-i3／i7-AES-HM76Z1FL.html

Contact us：
http://www.acrosser.com/inquiry.html

For COM Express to deliver real business benefit, it has to provide one other vital attribute: reliability. We are in the era of “always on” computing: The lights must never go out. And downtime means lost revenue. That’s a challenge in the harsh, hostile environments in which many critical infrastructure systems operate. Today’s connected world paradigm does not make a distinction between systems in stable environments such as offices and data centers, and systems deployed in harsh environments found in heavy industry, on factory floors, on drilling rigs, or on transportation systems.

These extreme industrial conditions require a ruggedized COM Express module. Specifically, they must operate in temperatures as low as -40 oC and as high as +85 oC – temperatures that are often found in oil and gas operations, for example. They must also withstand shock of up to 40g and extreme vibration from machinery or aircraft engines. Conformal coating is needed to resist the moisture, dust, and chemicals typical of industrial environments.

Designing, testing, qualifying, and manufacturing modular architectures for deployment in the hostile environments found in many critical infrastructure systems in industry is, therefore, a painstaking and rigorous process – but it is essential if maximum reliability and uptime are to be achieved. Modularity is helpful: By separating the processing module from the I/O carrier board, manufacturers can ensure that all the components on the processing module are specifically selected to meet application-specific extended temperature, shock, and vibration levels. It also becomes easier to test the module at maximum performance stress that can, for example, help the designers to reach an optimal heat sink solution with a uniform temperature profile early in the design cycle.

While considerable attention is paid to the design of processor modules as noted previously, the modularity of COM Express enables the development of carrier boards in parallel. Design and test engineers developing the processor module don’t have to wait until the entire carrier board is developed to verify the processor module design. This parallel – and even geographically dispersed – development can lead to lower time and cost of development while still providing a reliable solution for harsh industrial environments.

Reliable performance for today and the future

The flexibility to choose myriad differing price, power, and performance points makes the fully rugged COM Express modular architecture an outstanding choice for high-performance industrial automation applications for today’s connected world. Not only can rugged COM Express substantially lower lifetime total cost of ownership and extend the lifecycle of automation applications, they afford businesses the opportunity to harness the power and opportunity of the Industrial Internet while providing outstanding reliability.

refer to:http://industrial-embedded.com/articles/rugged-increasingly-connected-world/

 

 

The impact of the new standards to UAV developers using model-based design is especially significant. Before describing this, an introduction to model-based design is appropriate.
Introduction to model-based design

With model-based design, UAV engineers develop and simulate system models comprised of hardware and software using block diagrams and state charts, as shown in Figures 1 and 2. They then automatically generate, deploy, and verify code on their Embedded Systems. With textual computation languages and block diagram model tools, one can generate code in C, C++, Verilog, and VHDL languages, enabling implementation on MCU, DSP[], FPGA[], and ASIC hardware. This lets system, software, and hardware engineers collaborate using the same tools and environment to develop, implement, and verify systems. Given their auto-nomous nature, UAV systems heavily employ closed-loop controls, making system modeling and closed-loop simulation, as shown in Figures 1 and 2, a natural fit.
Testing actual UAV systems via ground-controlled flight tests is expensive. A better way is to test early in the design process using desktop simulation and lab test benches. With model-based design, verification starts as soon as models are created and simulated for the first time. Tests cases based on high-level requirements formalize simulation testing. A common verification workflow is to reuse the simulation tests throughout model-based design as the model transitions from system model to software model to source code to executable object code using code generators and cross-compilers.

An in-the-loop testing strategy is often used as itemized below and summarized in Table 2:

1. Simulation test cases are derived and run on the model using Model-In-the-Loop (MIL) testing.

2. Source code is verified by compiling and executing it on a host computer using Software-In-the-Loop (SIL) testing.

3. Executable object code is verified by cross-compiling and executing it on the embedded processor or an instruction set simulator using Processor-In-the-Loop (PIL) testing.

4. Hardware implementation is verified by synthesizing HDL and executing it on an FPGA using FPGA-In-the-Loop (FIL) testing.

5. The embedded system is verified and validated using the original plant model using Hardware-In-the-Loop (HIL) testing.
A requirements-based test approach with test reuse for models and code is explicitly described in ARP4754A, DO-178C, and DO-331, the model-based design supplement to DO-178C.

Transitioning to new standards using model-based design

ARP4754A addresses the complete aircraft development cycle from requirements to integration through verification for three levels of abstraction: aircraft, systems, and item. An item is defined as a hardware or software element having bounded and well defined interfaces. According to the standard, aircraft requirements are allocated to system requirements, which are then allocated to item requirements.

refer to:
http://mil-embedded.com/articles/transitioning-do-178c-arp4754a-uav-using-model-based-design/