Abstract-In this paper an approach to support the development process of closed-loop control software for Programmable Logic Controllers (PLC) is shown. To enhance the development process, a fast and reliable data transfer between different tools and models used during different design phases is realized by model transformation. A core model created using the Systems Modeling Language (SysML) and a corresponding model editor based on the Unified Modeling Language (UML) in combination with a newly realized model transformation from the SysML parametric diagram to the Simulink block diagram is used to integrate the information from different engineering tools and models involved during automation engineering design phases. Hence, a consistent process for the development of closed-loop control software is realized.
I. INTRODUCTION
When designing, simulating and implementing closed-loop control software for PLCs in automation several crucial steps are necessary during the design process. Furthermore, many aspects from a variety of disciplines, such as the geometrical measures from mechanical engineering, the structure of the controlled system from control engineering or the process from process engineering, must be taken into consideration. In each design phase different engineers from different disciplines are involved. However, the phases are not encapsulated and information from prior steps needs to be made available to the ones following. Up to now, manual extraction or transformation of information from one model to another is necessary, making the design phase time-consuming and prone to errors. Following this strain of thought, a core modeling language merging all information of the different phases seems necessary to provide a basis for gathering all information of a system. The Systems Modeling Language (SysML [1]) is a language, where most aspects, that need considering during the design phase of a plant and its software, can be depicted. It is an adaption of the Unified Modeling Language (UML), created to meet system engineers' requirements. Therefore, some diagrams and notations from the UML have been adopted and new diagrams have been defined. The SysML provides constructs to model structure, behavior, parametric coherences, etc. of system blocks [2]. However, SysML cannot replace all other tools in the design process, because some functionality, such as simulations of closed-loop controls, is not provided within SysML and the tools supporting this language. In the development process of the closed-loop control, firstly, the controlled system is modeled. This is an area of expertise of
the mechanical engineer. As current research projects show [3], mechanical engineers work well with SysML. The controlled system can be modeled within the parametric diagram, which is useful when modeling physical aspects of the plant, e.g. continuous systems, such as the controlled system of a component. The following development phase is the design and the simulation of the closed-loop control. Simulink is widely used and has its strengths in supporting the design and the simulation of closed-loop controls including simple tuning functions of the parameters. It is a graphic extension of MATLAB to enable interactive modeling and simulation of dynamic systems. In the MATLAB/Simulink environment the behavior of physical systems can be described and simulated using mathematical blocks. Simulation is not yet possible using solely SysML tools. The model of the controlled system designed in the prior step in SysML is crucial for the control engineer, and therefore it must be transferred into Simulink. In parallel to modeling the controlled system in SysML, several other production aspects are modeled as well, as for instance the process of a plant. To describe processes the activity diagram can be used. For this diagram among others, editors and codegenerators for PLC runtime-systems [4] have been realized successfully. Using these code-generators, the process engineer is enabled to simply model the process in detail in the activity diagram. After having finished this model it is transfered into the PLC-runtime environment. Single steps of a process have to be implemented as a closed-loop control, e.g. the operation of a pump, making the control of the pump flow necessary [5]. A combination of the works mentioned above enables a consistent development process for PLC automation software containing closed-loop controllers. However, to complete this concept and to make modeling a system in SysML as well as in Simulink easier, an automated transformation of the SysML parametric diagram to the Simulink block diagram has been implemented, which is presented in this paper. By these means different engineers are enabled to work in an environment they are comfortable with. The paper is structured as follows. First, related work is discussed. Subsequently, prior work and the missing link in form of a model transformation from SysML to Simulink, stating the mapping rules, is presented. The overall concept is evaluated using an application example from manufacturing automation in section IV. The last section sUlmnarizes the paper and gives an outlook on future work.
In this section first approaches stating concepts for integrated engineering processes are addressed. Following this, related work realizing tool coupling between SysML and Simulink is considered.
A. Integrated engineering through tool support
The support of engineers throughout the different engineering phases of mechatronic systems is a topic addressed by many researchers. Some works, such as the one proposed in this contribution, implement a core model whereas others rather focus on coupling tools along the development process. Thramboulidis et al. [6] and Shah et al. [7] identify SysML as a suitable language for capturing an integrated model of a mechatronic system. In [6] different views of a system are modeled and a central view captures the most important aspects. However, the need for other tools is acknowledged and the development of control code is supported, taking the aspects modeled in SysML into account. In [7] a platform keeping information consistent and on a central location is created. Through model transformation, data from the central model is passed on efficiently to other tools. In the approach presented by Secchi et al. [8] the mechatronic design and development processes are supported by extending the UML using the UML-RT profile to get a holistic view of the system. Using the tool Rose RealTime, code-generation is possible and system characteristics that should be regarded while implementing the PLC-runtime software can be identified. Maurmaier et al. [10] suggest a core model that describes the technical process in an abstract way. From this model the generation of different engineering documents and code through a set of transformation rules is made possible. Sequences of Operation are the method used by Lennartson et al. [11]. In this way a process is described abstractly to support production processes. However, in the works suggesting a core model introduced in this section, the development of c1osedloop control software is not explicitly focused and therefore a tool supporting the design of closed-loop controls and implementing the software with code-generation of closed-loop control software is not integrated into the concept. In contrast to the approaches mentioned above Lauder et al. [12], Estevez et al. [13] and Biffi et al. [14] do not aim at a core system model but at integrating different tools into the development process through tool coupling. In [14] this is achieved by metamodeling the different models that are used and defining mapping rules in between those tools. Estevez et al. [13] aim at preventing design errors through model checking. With model transformations and cross-checking of models the development process of control systems is supported. Biffi et al. [14] propose a broader concept of coupling tools to support mechatronic system development, including project, systems and software engineering but also team communication. Dubinin et al. [15] assist the development of control software explicitly for Distributed Control Systems by Function Block model transformation. By these means the behavior of the system is guaranteed in each execution model. In some of the approaches
focusing merely on tool-coupling instead of on a core model, a tool supporting the design of closed-loop controls is integrated into the tool coupling process, or at least into the concept of the integrated engineering process. However, a core model collecting all information and making it accessible to the engineers, such as the one suggested in this paper, is not a goal of these works and model transformation from SysML to Simulink has not been implemented yet.
B. Coupling SysML and Simulink
In the approach presented in this paper SysML and Simulink are coupled through automated model transformation from the SysML parametric diagramm to the Simulink block diagram. The transformation makes the controlled system modelled in SysML available to the engineers working with Simulink. In [16] the transformation is realized in the opposite direction, bringing information from Simulink diagrams into SysML, to achieve a holistic and complete representation of a system. This complete representation of a component further completes a core model in SysML. However, an appropriate support for the development of closed-loop controls is not enabled. In context of the AUTOSAR [17] project, a transformation of the SysML block diagram, which depicts the structure of a system, into the Simulink block diagram has been realized to transfer the structure of the machine, plant or component into Simulink. The transformation of parametric diagrams is not regarded and therefore the approach does not support the process of developing closed-loop controls. In the ParaMagic [18] plugin constraint blocks are transformed into MATLAB, simulated, and the results carried back to SysML. However, complete diagrams are not transformed and thusly the design phase in Simulink is not fully supported. In conclusion, no complete support of the development process for closed-loop control code for PLC, and more specifically, no mapping rules for the SysML parametric diagram to the Simulink block diagram were identified.
III. CONCEPT
The model transformation of parametric diagrams to Simulink block diagrams complements prior work of the authors which is introduced in the following. The tools connected in the development process proposed in this paper for PLC software are shown in Fig. 1. UML diagrams, such as the activity diagram and the state chart diagram, which are also part of the SysML, have been implemented as a UML-Plugin for the PLC progranuning environment CoDeSys [19], creating the so-called technology-editor [4] (Fig. 1). With the technologyeditor, the activity diagram is in fact the implementation of the PLC program. The diagram is automatically translated internally for the PLC run-time system (step 3). The different actions in the activity or state diagram are implemented in the IEC 61131-3-conform languages like structured text (ST), but masked within an activity. It is also possible to include Continuous Function Chart (CFC) code into the activities. The implementation of closed-loop controllers is required within some of the acitivties. A manual transfer of the model created
6186
SysML-Editor : UMLlIEC61131-3
: Technology-Editor
parametric diagram I activity diagram
CD. ®J� 0. ,-__ =--L ____ ��
Matlab/Simulink
Block Diagram I PLC
run-time system
Fig. l. Models and tool coupling in the development process of closed-loop control software.
in Simulink into the CoDeSys environment is not necessary, because a code generator has been developed and presented in [5], enabling the automatic generation of CFCs from controllers in Simulink, taking PLC properties into consideration (step 2). Combining these approaches, the different models in the development process are all supported and linked to a SysML core model, excluding the link between SysML and Simulink. To close the gap between developing PLC c1osedloop control software a SysML editor for parametric diagrams and Simulink were coupled and the required mapping rules between the models were realized (step 1). The SysML Editor was used because the technology-editor containing the process modeled as an activity diagram does not fully support SysML and its parametric diagram yet.
In the following the transformation of the parametric diagram to the Simulink block diagram is presented. Therefore, an introduction of both diagrams is given to demonstrate which elements are of importance for the transformation. Subsequently, the identified mapping rules are explained.
A. Parametric diagram
The SysML diagrams can be structured into behavioral diagrams and structural diagrams. Behavioral diagrams include e.g. activity diagrams, which provide the notational elements to model production processes. Structural diagrams may be used to show structural aspects of a system. In contrast to both, the requirements diagram enables engineers to model system requirements. This diagram could neither be subordinated as a structural nor as a behavioral diagram. The parametric diagram is classified as one of the structural diagrams of SysML. It is a diagram newly created and derived from the internal block diagram, where the structure of components and their connections to one another are shown. The internal block diagram describes the internal structure of a system or component with parts, ports and connectors. In contrast, the parametric diagram describes physical interdependencies (e.g. F = m . a). It enables the engineer to model discrete as well as continuous systems. The parameters of a component are described as attributes of a block within the parametric diagram, the mathematical interdependencies are depicted in textual form as so-called constraints contained in constraint
blocks. In Fig. 2 a parametric diagram, which contains all elements defined for the parametric diagram in the SysML, is shown. "Block 1" contains a part property "B3" with "Block3" as type, a value property "a" and the constraint block property
«block» Block1
«block» B3: Block3
Fig. 2. A basic parametric diagram.
"CB2" of the type "ConstraintBlock2". This constraint block
contains a constraint (c = a· 3 + b) that specifies the value of the output parameter "c".
B. Simulink Block Diagram
The Simulink library offers a selection of standard blocks, both continuous, for instance controllers, and discrete blocks, for instance mathematical operations, etc. Time-varying systems from engineering activities such as controller development are explicitly supported. The Simulink block diagram may be structured using subsystems. A subsystem may be the system which is controlled, but also a small group of blocks masked with a subsystem.
C. Model Transformation
The scheme of a closed-loop control is shown in Fig. 3. The block, emphasized by the dashed rectangle represents the plant or the process that is controlled. It represents the transformed model and is in the focus of this paper.
Controller
Fig. 3. Scheme of a closed-loop control.
For each element of the parametric diagram, objects with similar characteristics were identified and mapping rules were defined (see Table I). The block and the part property in the parametric diagram are basically the objects that structure the plant and the model. This function is fulfilled by subsystems
in Simulink. Typical subsystems are for instance the controlled system of a plant or a controller. Obvious mapping rules are the port that is transformed into either an in- or an outport, and the connectors which are transformed into lines and branches.
The value property of the parametric diagram is meant to be read out as well as read in. A block allowing the same operations in Simulink is the Data Store Memory Block, when also generating the corresponding Data Store Read and Data
Store Write Blocks. Value properties of a controlled system are all the parameters that influence it. While transforming the
6187
TABLE I MAPPING OF MODEL ELEMENTS
Parametric Diagram Simulink Block diagram Block, Part Property Subsystem
Port Inport/ Outport
Connector Line, Branch
Val ue Property Data Store Read, Write and Memory
Constraint Block Embedded MATLAB function
parametric diagram, all three blocks are generated to represent the value property, The physical constraints a component has to maintain are modeled using constraint blocks in the parametric diagram, In Simulink there is a wide variety of blocks that implement mathematical operations. However, the opportunity of importing whole mathematical functions from MATLAB also exists when using the Embedded MATLAB
Function. The Embedded MATLAB Function is an extension of the Fen-Block. When starting a simulation in Simulink an executable file is generated out of this block. Like a constraint
block the Embedded MATLAB Function may have several inputs. For these reasons and to maintain the graphical similarity between the transformed models to increase usability, the mapping rule was formulated between these two blocks. For the constraint to be correctly transformed, the constraints have to be formulated according to the MATLAB notation rules, e.g. abs(x) for the absolute value of x and so on. In contrast to this the constraints are usually formulated according to the Object Constraint Languange (OCL) [20] rules. If a specific block of the Simulink standard library is explicitly desired a standard constraint block can be defined in SysML, and the complementing mapping rule can be defined. A block where this was already necessary is a block integrating the input value over the simulation time. In the SysML Editor it is not possible to simulate continuous systems, therefore the simulation time can not be taken into consideration when executing a model within this editor. To generate an executable model in Simulink a standard "integrator block" was defined in SysML and the according mapping rule was formulated. To set this transformation into motion, the modeler simply has to name the modeled constraint block with the standardized name "integrator", of which an example can be found in section IV.
IV. ApPLICATION AND EVALUATION
To demonstrate the design process of implementing a closed-loop control in IEC 61l31-3, components of a laboratory plant are considered for the development of a closed-loop control. The considered component is a rotary track switch that can be controlled by alternating the input voltage. The track switch has to route products between different conveyors and different angles (see Fig. 4). The parameter desired to adjust is therefore the angle where the track switch should be aligned in order to take in and pass on products.
Fig. 4. The rotary track switch.
A. Application Example
Firstly, the activities within the production process that are performed by the track switch were modeled using the technology-editor. By this the activity diagram modelling the process of a plant was integrated into a CoDeSys PLC environment (Fig. 5, A: technology-editor - activity diagram). Important process steps in this activity diagram are the activities "turnLeft" and "turnRight" because they need to implement controllers. Following this, the physical interdependencies of the track switch were modeled within a SysML parametric diagram (Fig. 5, B: SysML editor). This model represents the controlled system. To make the information modeled in the parametric diagram available to the control engineer, an automated model transformation of the parametric diagram into a Simulink block diagram was performed (Fig. 5, step 1). The model contains two constraint blocks whose operation is to integrate the input over the simulated time. For this operation a Simulink block does exist in the standard library and an additional mapping rule was defined as described in section III B). To ensure the correct transformation of these blocks, they were named "integrator" as presented previously. The transformed diagram is masked within a Subsystem "track switch" and can be seen in Fig. 5 as the block, which is highlighted by a dashed rectangle (Fig. 5, C: Simulink). This way the controlled system was made available to the control engineer as a template for the complete closed-loop control in Simulink. After having simulated this system, the control engineer included a PID controller into the model (Fig. 5, C:Simulink). Using Simulink, the design and the simulation of the closed-loop control was done in a fast and efficient way, using the support offered by Simulink to tune the PID controller. Having finished design and simulations in Simulink, the controller was transformed into CFC-code (Fig. 5, step 2) and imported into the technology-editor (Fig. 5, A: technology-editor). The elements that were transformed can be seen as the part highlighted by a dashed-dotted rectangle. Subsequently, the process steps modeled earlier in the activity diagram could be associated with the CFC-code (Fig. 5, A: technology-editor). Further on, the relevant parameters of the in- and outputs of the CFC within the activity diagram could
L-� Subsystem: controlled system track switch 9 Transformation
.- .. L . J Part of Simulink model that is transformed to CFC :" .... ' Activity that is implemented by the CFC closed-loop control
Fig. 5. The transformation and code generation from one tool/model to another in the development process of closed-loop control software
be associated with the hardware of the system and the diagram with its IEC 61131-3 code could be translated internally during runtime.
B. Evaluation
The CFC-code generator and the UML-Plugin have been evaluated extensively in prior work [4], [5]. The model transformation between the parametric diagram and the Simulink block diagram has been evaluated for time invariant models as well as for continuous models. Since the SysML editor used for parametric diagrams allows the calculation of discrete models, representing basic mathematical operations, the evaluation could be done by comparing outputs of an original SysML model with the transformed Simulink models. Several outputs, e.g. the energy height of a pump, were
compared to the transformed Simulink models. The outputs were validated in every model transformed. The second way the transformation was evaluated was by first creating the targeted model in Simulink, then creating the complementary model in SysML. The SysML parametric diagram was then transformed and the resulting model could be compared to the template model first created in Simulink. In the evaluation, three of these transformations were evaluated, one being a basic parametric diagram another being the controlled system of a tank system, and no mistakes were found in the models that were transformed. Having evaluated and implemented the transformations and having further on implemented the application example of the track switch in the design phase with constant help of automated transformations, it was shown,
6189
that a development process of PLC-code is possible without the engineers being forced to manually transfer or extract information from models. In this way mistakes in the design phases following prior steps could be avoided and a consistent data flow was guaranteed.
V. CONCLUSION AND OUTLOOK
In this paper an integrated development process to support closed-loop control software development for PLCs has been described. It was shown that the implemented model transformation described combined with prior work can support the engineering process of modeling and implementing c1osedloop control software nearly throughout the whole process. Several aspects of the plant or machine can be modeled in a SysML core model with the import of additional information from other models. The process of a system is modeled within an activity diagram, controlled systems within a parametric diagram. Information needed from the parametric diagram for designing a closed-loop control can be transferred automatically to Simulink, where control engineers are able to design a closed-loop control and make refined tunings of controllers. In the next step the controllers are transferred into PLC-code, namely CFC-code. With the activity diagram, which is in itself the implementation of the PLC-code and is modeled in the technology-editor the program is now complemented by the CFC-implementation of the controllers. To complete the core model, a transformation back from Simulink to SysML, similar as the one realized in [16], but from the Simulink block diagram into the parametric diagram, is a goal desired by the authors. Further on, the integration of the technology editor and other SysML editors, such as the editor for parametric diagrams, is a focus in future work. Another important aspect that still needs to be integrated into the tool-support, is model-checking of the parametric diagram during modelling. To increase the reliability of the model transformation a check of the constraints in respect to MATLAB conformity as mentioned in section IV C is needed. Another aspect desirable in addition to the current transformations is the transmission and the tracking of requirements, which can be modeled in the SysML requirements diagram. Requirements such as nominal values or cycle times for the closed-loop controls already defined in the SysML model could be transformed automatically into Simulink, guaranteeing the correct transfer of this data. Furthermore, a central subversion server, where all tools used during the development process can be linked in order to track updates, changes and progressions is a goal pursued by the authors.
REFERENCES
[I] (2012) Systems Modeling Language Specification. [Online]. Available: http://www.omg.orgispec/SysML/
[2] H. Espinoza, D. Cancila, S. Selic, and S. Gerard, "Challenges in Combining SysML and MARTE for Model-Based Design of Embedded Systems," Model Driven Architecture - Foundations and Applications,
Lecture Notes in Computer Science, vol. 5562, pp. 98-113, 2009. [3] Design, implementation and evaluation of a tool-supported method for
the development of agent systems in automation technology, taking into account the usability (KREAagentuse), Deutsche Forschungsgemeinschaft (DFG) funded Project (VO 937/8-1).
[4] D. Witsch and B. Vogel-Heuser, "Close integration between UML and IEC 61131-3: New possibilities through object-oriented extensions," IEEE Conference on Emerging Technologies and Factory Automation (ETFA), pp. 1-6, 2009.
[5] G. Bayrak, D. Renzhin, and B. Vogel-Heuser. "Integration of control loops in an UML based engineering environment for PLC," IEEE
Conference on Emerging Technologies and Factory Automation (ETFA), pp. 1-8,2011.
[6] K. Thramboulidis and A. Buda, "3+ I SysML view model for IEC 61499 Function Block control systems," 8th IEEE International Conference on Industrial Informatics (INDlN), pp.175-180, 2010.
[7] A. A. Shah, D. Schaefer, and C. 1. 1. Paredis, "Enabling multi-view modeling with SysML profiles and model transformations," Proceedings of the 6th International Product Lifecyc/e Management Conference, pp. 527538, 2009.
[8] C. Secchi, M. Bonft\ and C. Fantuzzi, "On the Use of UML for Modeling Mechatronic Systems," IEEE Transactions on Automation Science and Engineering (TASE), vol. 4, no. 1, pp.105-113, 2007.
[9] (2012) Rational Rose RealTime. [Online]. Available: http://www-01. ibm.com/software/awdtools/developer/technical/
[10] M. Maurmaier and P. Gohner, "Model-driven development in industrial automation - Automating the Development of Industrial Automation Systems using Model Transformations," Sixth International Conference on Informatics in Control, Automation and Robotics (ICINCO), 2009.
[II] B. Lennartson, K. Bengtsson, Chengyin Yuan, K. Andersson, M. Fabian, P. Falkman, and K. Akesson, "Sequence Planning for Integrated Product, Process and Automation Design," IEEE Transactions on Automation Science and Engineering (TASE), vol.7, no.4, pp. 791-802, 2010.
[12] M. Lauder, M. Schlereth, S. Rose, and A. Schlirr, "Model-Driven Systems Engineering: State-of-the-Art and Research Challenges," Bulletin of the Polish Academy of Sciences, Technical Sciences, vol. 58, no. 3, pp. 409-422, 2010.
[13] E. Estevez and M. Marcos, "Model based Validation of Industrial Control Systems," IEEE Transactions on Industrial Informatics, vol. 8, no. 2, pp. 302-310, 2012.
[14] S. Bim, A. Schatten, and A. Zoitl, "Integration of heterogeneous engineering environments for the automation systems lifecycle," 7th IEEE International Conference on Industrial Informatics (INDIN), pp. 576-581, 2009.
[15] Y. Dubinin and Y. V yatkin, "Semantics-robust Design Patterns for IEC 61499," IEEE Transactions on Industrial Informatics, vol. 8, no. 2, pp. 279-290, 2012.
[16] A. Qamar, c. During, and 1. Wikander, "Designing Mechatronic Systems, a Model-based Perspective, an Attempt to Achieve SysMLMATLAB/Simulink Model Integration," IEEEIASME International Conference on Advanced Intelligent Mechatronics, pp. 1306 - 1311,2009.
[17] G. Sandmann and R. Thompson, "Development of AUTOSAR Software Components within Model-Based Design," SAE World Congress, 2008.
[18] (2011) No Magic Incorporation, ParaMagic Plugln. [Online]. Available: https:llwww.magicdraw.com/paramagic
![Page 1: [IEEE IECON 2012 - 38th Annual Conference of IEEE Industrial Electronics - Montreal, QC, Canada (2012.10.25-2012.10.28)] IECON 2012 - 38th Annual Conference on IEEE Industrial Electronics](https://reader035.documents.pub/reader035/viewer/2022073110/5750935a1a28abbf6baf6026/html5/thumbnails/1.jpg)
![Page 2: [IEEE IECON 2012 - 38th Annual Conference of IEEE Industrial Electronics - Montreal, QC, Canada (2012.10.25-2012.10.28)] IECON 2012 - 38th Annual Conference on IEEE Industrial Electronics](https://reader035.documents.pub/reader035/viewer/2022073110/5750935a1a28abbf6baf6026/html5/thumbnails/2.jpg)
![Page 3: [IEEE IECON 2012 - 38th Annual Conference of IEEE Industrial Electronics - Montreal, QC, Canada (2012.10.25-2012.10.28)] IECON 2012 - 38th Annual Conference on IEEE Industrial Electronics](https://reader035.documents.pub/reader035/viewer/2022073110/5750935a1a28abbf6baf6026/html5/thumbnails/3.jpg)
![Page 4: [IEEE IECON 2012 - 38th Annual Conference of IEEE Industrial Electronics - Montreal, QC, Canada (2012.10.25-2012.10.28)] IECON 2012 - 38th Annual Conference on IEEE Industrial Electronics](https://reader035.documents.pub/reader035/viewer/2022073110/5750935a1a28abbf6baf6026/html5/thumbnails/4.jpg)
![Page 5: [IEEE IECON 2012 - 38th Annual Conference of IEEE Industrial Electronics - Montreal, QC, Canada (2012.10.25-2012.10.28)] IECON 2012 - 38th Annual Conference on IEEE Industrial Electronics](https://reader035.documents.pub/reader035/viewer/2022073110/5750935a1a28abbf6baf6026/html5/thumbnails/5.jpg)
![Page 6: [IEEE IECON 2012 - 38th Annual Conference of IEEE Industrial Electronics - Montreal, QC, Canada (2012.10.25-2012.10.28)] IECON 2012 - 38th Annual Conference on IEEE Industrial Electronics](https://reader035.documents.pub/reader035/viewer/2022073110/5750935a1a28abbf6baf6026/html5/thumbnails/6.jpg)
![Program for 2015 ieee international conference on consumer electronics taiwan [ieee icce-taiwan 2015]](https://static.documents.pub/doc/80x56/55cb7de6bb61ebb64f8b4834/program-for-2015-ieee-international-conference-on-consumer-electronics-taiwan.jpg)
![IEEE TRANSACTIONS ON POWER ELECTRONICS, 2007] Mixed... · 2018-01-30 · IEEE TRANSACTIONS ON POWER…](https://static.documents.pub/doc/80x56/5b4abb5f7f8b9af5078e54eb/ieee-transactions-on-power-electronics-2007-mixed-2018-01-30-ieee-transactions.jpg)
