Views

Enterprise:Engineering

Contents

Navigation

Home · Main Page · Enterprise  ·


Categories



Automation, agile manufacturing and distributed control systems

Agility requires dynamic reconfiguration at minimal cost and with minimal human intervention. For this reasons advanced product-line automation is required and this is primarily based on standards for open distributed automation, like IEC 1131-3 and its successors.
These standards define the information-exchange mechanisms, the methodology, semantics and language for formally describing the structure and behavior of programmable-logic control systems.
Examples of formal specification methodologies are :
  • Ladder Diagram (LD) for logic control (“power flow”), described by standard IEC 1131-3
  • Function Block Diagram (FBD) for regulatory control (“data flow”), described by standards IEC 61804 and IEC 61499
  • Sequential Function Chart (SFC) for state-machine control, defibed by standard IEC 61131-3 and IEC 61499

For the information-exchange the standards define the so-called Fieldbus architecture, a generic term designation an industrial-control digital communication network replacing the analogue current-loop legacy communication standard. There have been many proprietary Fieldbus technologies, like Profibus, ModBus, WorldFIP, Bit-Bus, etc. All these are converging into the unified Open Fieldbus specification, defined by standard IEC 61158
Currently there is a convergence between the the Programmable-Logic Control and Information Technology disciplines, enough to mention that the IEC 61499 standard is using a Service Oriented Architecture for the communication among devices, resources, applications and function blocks.

Configuration Management and Change Control in Engineering Practice

The Configuration Management and Change Control practice is important in all engineering fields, especially in enterprises having put in place a Quality Management System based requiring a level of "documentation control", from mechanical drawings to software programs.

A number of Quality Management frameworks recomment the configuration management as a key process area to be audited for. The Quality management practices create the need for versioning, baselining and change control in product-delivery activities and, in fact, all engineering practices create the need for versioning, baselining and change control for product documentation. Operational best-practices, like ITIL or ISO-IEC 20000, insist on using configuration- and change-control procedures for service-delivery activities. Information security best practice recommend as well using change control, configuration auditing and management procedures to minimize the risk of creating security holes in operational environments. Multifaceted elements of Configuration management can also be found under various names in many business processes as base components that span all engineering disciplines, in order to increase information integrity, minimize rework and improve overall efficiency. This approach is taken by the CMII framework, promoted by the CMII Institute, that tries to optimize the heavy-weight configuration- and change-management processes recommended by standards as ISO/IEC 10007 or IEEE STD 1042-1987.

All engineering practices that intervene in a product life-cycle, as well as the associated project management practices, need in a form or another to track all the product-associated information, from the drawing board to the production floor. This is actually much larger as scope and quite different than the Configuration- and Change-Management disciplines applicable in Software Engineering and IT Service Management and covered by the Product Data Management (PDM) discipline.

The information about products is multi-faceted, may have a large volume and be scattered across an organization's functional units, therefore the need arises to efficiently consolidate, categorize, identify and manage change for it. This is the domain of Product Information Management (PIM) practice and it is about providing complete, consistent and updated product information over a variety of internal and external channels and in different formats.

The most common domain for configuration control and change management is IS/IT Operations, where standards like ITIL and ISO/IEC 20000 govern the IT Service Management (ITSM) process, structured around the concept of a central Configuration Management Database (CMDB). Specific requirements for Configuration- and Change management are also found in Quality Management frameworks like CMMI, ISO 9001:2000, IEEE STD 828-1990 (Software Configuration Management Plans) and IEEE STD 1042-1987 (Software Configuration Management).

In order to put in place policies for Configuration- and Change Management, specialized tools exist, the most common in software engineering being Clearcase, CVS, Subversion and PVCS.

Quality Management and Quality Assurance practice

Quality Management in general is a vast domain spanning all engineering disciplines and extremely important in manufacturing operations. Of particular importance, in our information-driven society, is the Quality Management practice in Software Engineering, Information Technology and IS/IT Operations. Institutions like the Quality Assurance Institute or American Society for Quality Assurance recommend effective solutions, technologies, concepts, tools, and training for quality management in the information services profession. The I Six Sigma organization grants Certifications and Awards (Balridge, etc) to individuals and organizations for achievements in Quality Assurance.

In particular, the Software Quality Assurance (SQA) discipline has many facets, from processes, standards and methodologies to specialized toolsets. The real problem in the world of SQA is the 'quagmire' of existing methodologies, frameworks, standards, conformance criteria, maturity models, many of them similar in many respects to each other. Some large organizations tend to adopt generic process-improvement framework, like ISO 9001:2000, CMMI,RUP or Fujitsu/DMR Macroscope. Other organizations tend to introduce in their processes best practices derived from SQA-specific standards issued by IEEE or ISO. The "Evaluation Assurance Levels" (EAL) criteria defined by the "Common Criteria" ISO/IEC 15408 standard or the Financial Institution Shared Assessments Program (FISAP) for IT outsourcer assessment, look, among other things, to a supplier's Quality Management System and are extremely important for product or service selection by financial institutions.

Many software organizations have product testing departments which are named "Quality Assurance". In fact, Quality Management is much more than testing, it is mainly defect prevention by encompassing all phases and processes in the product life-cycle. For this reason, managing defects in software products rely on process control through multi-faceted defect metrics formalized by IBM's Orthogonal Defect Classification (ODC) and the ISO/IEC 9126 standard. Specialized issue- and bug-tracking tools, like Bugzilla, GNATS or Mantis, come to rescue. The Cleanroom Software Engineeringis an engineering methodology and management process, aims at delivering zero-defect, certified reliability software products, while the ISO/IEC 12207 standard aims at implementing the Total Quality Management principles in Software Engineering practice. The ISO/IEC 12220 series provides detailed guidelined on the supporting processes of ISO/IEC 12207. The ISO/IEC 15504 standard, known as SPICE (Software Process Improvement and Capability Determination) is a "framework for the assessment of software processes", derived from ISO 12207 and using many of the CMMI concepts. The ISO/IEC 15939, "Software Engineering - Software Measurement Process" was developed based on the Practical Software Measurement (PSM) guidelines pioneered by the US DoD. The Software Testing discipline has evolved from the need of preventing software defects. The Risk-based testing approach relies on Pareto's 80-20 principle stating that as much as 80% of the consequences can be traced back to only 20% of the causes. The Risk-based testing would rely on a risk analysis and on the evaluation of business impacts defects may have, based on the framework defined in ISO/IEC 9126 and is defining a methodology of finding the most important defects as early as possible at the lowest price.The Test Maturity Model (TMM) proposes a process improvement framework for the Software Testing function.

Engineering communities and interest groups

Various resources and information in different areas of the engineering practice are available through the online forums and special interest groups are available in the Engineering communities page:

Resources for the Engineering Practice

Unclassified informations, useful for engineers working in the hi-tech field, can be found in the Resources page:
  • Software Engineering Resources - modeling, programming, cluster computing, file and data formats, standards
  • High Availability systems and fault-tolerant computing
  • Embedded and Electronics engineering - microprocessors, real-time computing, robotics, digital-signal processing (DSP)
  • RISC computing - PowerPC, MIPS, ARM
  • Specialized network processors for wire-speed packet analysis, classification, marking and switching
  • Hardware design - VHDL, hardware interfacing
  • Specialized applications - avionics, point-of-sale (POS), medical digital imaging (DICOM)
  • Storage technologies - RAID, SAN, iSCSI
  • Electro-nagnetic Compliance (EMC)


Mathematics for the Engineering practice

Often neglected, a good handle on Mathematics is still essential in all engineering practices:
  • Geometry, statistics, numerical and complex analysis, numerical recipes, hamming codes (HEC), algorithms
  • Excel solver, financial technical analysis, Markov chains, distributions, Monte Carlo method, cryptography
  • Fractals, Chaos theory, queuing theory, operational analysis, linear optimization and regressions