CAN AUTOMATION VENDORS SERVE TWO MASTERS?

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.
Inherent Conflict

The dynamics of a service business and innovative product business are dramatically different. Established product companies tend to emphasize the practices and culture they know best when they move into services. The tendency is to find synergies based on their products that become the recommended solutions for customers. Additionally, it can be more difficult for a product company who provides services to be the champion for the customer when there is a problem with the product being implemented.
Ideal Product Company Focus

I believe that product companies should always be striving to eliminate implementation and operations labor with improved and innovative automation technology. There is an inherent conflict by having a company that provides services and products.

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

Acrosser unveils its ultra slim fanless embedded system with 3rd generation Intel core i processor

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

Industrial automation systems are performing more tasks and doing so more quickly

industrial automation systems are performing more tasks and doing so more quickly, more accurately, and in harsher environments than ever before. They are becoming connected tools with substantially more computing and communication capabilities, allowing them to interoperate with other devices. As they evolve and proliferate, these systems put new demands on their computing technology. Rugged COM Express modules not only meet the computing needs of today’s rapidly changing industrial landscape, but also protect the investment to meet tomorrow’s performance needs.

At the dawn of the “Industrial Internet,” the ante is being upped for modular embedded systems. More and more machines are being connected, many in remote and challenging environments such as oil and gas, locomotives, transportation, and ship-propulsion systems. To meet the demand for more data in less time, these systems must work faster and longer. Accelerating with the demand for data is the evolution of computer processors. But businesses can’t afford the downtime required to replace processors, or the expense of replacing the carrier board when upgrading the processor. According to a 2006 Department of Energy study, idle industrial machinery can cost as much as $800 per minute.


What’s needed is a modular embedded computing architecture that addresses these cost and downtime issues. Perhaps the most compelling of the modular architectures available today is COM Express. COM Express provides the requisite computing power for today’s increasingly connected world while also extending the lifespan of the underlying system. As chip technology evolves, users can switch out the module without adverse effect on the underlying hardware and assets – saving time and money. The modularity, simplicity, and reliability of COM Express technology help businesses remain competitive, profitable, and flexible.

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

Transitioning to DO-178C and ARP4754A for UAV software development using model design

With the FAA and EASA adopting aviation standards such as DO-178C and ARP4754A, UAV software developers should familiarize themselves with these standards, particularly when transitioning to model-based design.
Few applications place more importance on verification, or prescribe more process guidance, than aviation. The FAA and its European equivalent, EASA, provide guidance using standards such as ARP4754 for aircraft systems and DO-178B for flight software. These standards are often used outside of civil aviation, in whole or in part, for applications including military aircraft and land vehicles. Adoption for UAV programs is rapidly growing because of the FAA’s recent decision to require UAS and OPA certification via FAA Order 8130.34A. UAV systems are heterogeneous, and not restricted just to flight software. Therefore, other standards are used such as DO-254 for hardware and DO-278 for ground and space software.
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.
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.
The fact that ARP4754A addresses allocation of system requirements to hardware and software components is significant to UAV developers, especially suppliers. Some suppliers might have claimed that UAV subsystem development was beyond the scope of the original ARP4754, even for complex subsystems containing hardware and software, but not anymore. ARP4754A also more clearly refers to DO-178 and DO-254 for item design. In fact, the introductory notes for ARP4754A acknowledge that its working groups coordinated with RTCA special committees to ensure that the terminology and approach being used are consistent with those being developed for the DO-178B update [DO-178C].
Given the high coupling among systems, hardware, and software for UAVs, it is helpful that the governing standards now clarify relationships between systems and hardware/software subsystems.
ARP4754A recommends the use of modeling and simulation for several process-integral activities involving requirements capture and requirements validation.
ARP4754A Table 6 recommends (R) analysis, modeling and simulation (tests) for validating requirements at the highest Development Assurance Levels (A and B). For Level C, modeling is listed as one of several recommendations. While ARP4754 made similar recommendations, ARP4754A provides more insight and states that a representative environment model, such as the plant model shown in Figure 1, is an essential part of a system model.
Also noted in ARP4754A is that a graphical representation or model can be used to capture system requirements. The standard now notes that a model can be reused for software and hardware design.
If engineers use models to capture requirements, ARP4754A recommends engineers consider the following:
1. Identify the use of models/modeling
2. Identify the intended tools and their usage during development
3. Define modeling standards and libraries
When using model-based design with ARP4754A and DO-178C, additional verification capabilities are often needed beyond in-the-loop testing described in Table 2. These including requirement tracing, model standard checking, model-to-code structural equivalence checking, and robustness analysis using formal methods. For UAVs, rigorous verification that includes multiple verification technologies is paramount given their autonomous nature and system complexity.
DO-178C
Not surprisingly, one of the first changes new in DO-178C is an explicit mention of ARP4754A in Section 2: System life-cycle processes can be found in other industry documents (for example, SAE ARP4754A).
Clarification updates aside, such as the one noted earlier, DO-178C does not differ significantly from DO-178B, at least at first glance. In fact, a casual reader might miss an item mentioned in Section 1.4: How to Use this Document: One or more supplements to this document exist and extend the guidance in this document to a specific technique… if a supplement exists for a specific technique, the supplement should be used …
In other words, the standard’s big changes are captured in the supplemental documents, such as RTCA DO-331, Model-Based Development and Verification Supplement to DO-178C and DO-278A.
Pertinent to this discussion, a long-standing issue with DO-178B for practitioners of model-based design is the uncertainty in mapping DO-178B objectives to model-based design artifacts. Addressing this mapping was a main goal of the DO-178C Sub-Group (SG-4) focused on model-based design. No single mapping sufficed, so several mappings are provided in DO-331. Some include the concept of a Specification model, which is a model separate from that of the one used for design and code generation. The other concept is a Design model, which serves as the detailed requirements used to generate code.

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