Control systems engineering processes using the IEC 61499-based MVCD framework can take maximum advantage of its highly visual nature. The operation of the controlled machine or process, and the associated control algorithms, should be visualized (preferably in an animated representation) as early as possible as in the systems engineering activity. This visual orientation should be maintained throughout the systems engineering process. The process illustrated above has been found effective in achieving these goals. See the Examples for step-by-step illustrations of the process.

1. Start with a sketch of the machine or process to be controlled, along with a verbal description of the desired behavior. This may be included in a hypertext document with links to existing process specifications and CAD drawings, but should abstract such detailed information into a high-level view of the desired functionality.
2. From the sketch, develop and test a number of Views which are capable of presenting visually the essential information about the states of the controlled devices, e.g., the location of workpieces, the position of tools, the state of spindle motors, the temperature or level of liquids in a tank, etc. A suitable layered architecture for performing this task is illustrated in the figure below.
   • The Local Multicast design pattern can be used for inter-layer communication.
   • The Tagged Data design pattern can be used to simplify and avoid errors in this step.
   
3. Using the architecture shown above, integrate the views into a static animation of the system to be controlled, and utilize the animation to develop descriptions of the desired operational sequences of the system under both normal and abnormal conditions.
4. For each view, develop and test one or more Models capable of simulating the dynamic behavior of the associated machine or process equipment in response to external stimuli and commanding the associated view to display the corresponding equipment states. Models should typically execute in their own threads of execution, e.g., in conjunction with external or internal timers or integrators. The layered architecture shown below can be used to test Models in conjunction with their Views and HMI elements.
   • The Local Multicast design pattern can be used for inter-layer communication.
   • The Tagged Data design pattern can be used to simplify and avoid errors in this step.
   • In some cases, Models and their associated Views may be represented by IEC 61499 service interfaces to external simulation or animation applications.
   
5. Encapsulate control logic in Controller blocks as necessary to achieve additional required functions, e.g., sequencing of the simulated equipment, event and data interfaces for integration with other controller blocks. The layered architecture shown below can be used to test Controller elements in conjunction with their associated Model elements.
   • The Local Multicast design pattern can be used for inter-layer communication.
   • The Tagged Data design pattern can be used to simplify and avoid errors in this step.
   
6. Add diagnostic and fault recovery logic and test together with the previously developed Models, Views and Controllers. The layered architecture shown below illustrates the testing of simple Diagnostic elements in conjunction with their associated Controller and Model elements. In this case, the Diagnostic elements are simply monitoring actuator outputs and sensor inputs and reporting whether they are occurring in the correct combinations and sequences. The following principles will help you to maximize the benefits of applying the IEC 61499 architecture to fault detection, diagnosis and recovery:
   • Keep fault detection, diagnosis and recovery functions as close as possible to the equipment being controlled. It is much easier to detect, diagnose and recover from faulty operation of an individual machine or control component, based on deviations from its expected behavior, than to deduce the cause of a system crash once the fault has occurred. This rule is illustrated by those function block whose end with the suffixes _DIAG and _DIAGL .
   • Avoid complexity in control functions and improve reusability of both control and fault functions by encapsulating fault detection, diagnosis and recovery functions separately from control functions.
   • Include the capability of injecting fault conditions either manually at the View level or automatically at the Model level. In the current examples, each of the *_VIEW function blocks shown in the index has a FAULT data output, associated with an IND event output, which can be set or reset by clicking on a "fault indicator" in the upper left-hand corner of the user interface. The TRUE or FALSE state of the FAULT output is indicated by a red or green color of the fault indicator, respectively. In the Model elements, the FAULT condition inhibits motion to simulate failure of an actuator element.
   • Establish an architecture for reporting and logging faults and diagnostics. This may include an appropriate HMI such as an instance of the DIAG_LOG type.
   • The Local Multicast design pattern can be used for inter-layer communication.
   • The Tagged Data design pattern can be used to simplify and avoid errors in this step.
   
7. Perform distribution design by allocating Model elements to separate devices and converting local communication links to distributed links as shown in the figure below.
   • The Tagged Data design pattern can be used to simplify and avoid errors in this step.
   
8. Perform physical design: Replace Model/View complexes by service interfaces to actual control system I/O as shown below.
9. Perform mechatronic design as shown below:
   • Partition control and diagnostic blocks into high-level (HLC) blocks which cross device boundaries, and which cannot be accomplished by simple interconnections of existing low-level control (LLC) blocks, e.g., mode control, systemwide startup, diagnostic reporting, etc.
   • Allocate function block instances to the integrated controllers of specific mechanical devices, adding communication function blocks as necessary to maintain data and event connections. This may involve the use and configuration of existing mechatronic devices where available.