近年来，日益广泛而复杂的整合式IC设计与设计时间的压缩，任何在整合软、硬件时所发生的问题，都可能成为整个研发计划失败的致命伤。为了跳脱旧有窠臼，许多公司不得不重新思考其传统的软件设计流程，新的研发流程必须把从观念到软、硬件整合测试(System Integration Test)各个面向都纳入考虑。在新的设计环境下，任何阶段的研发工具不能只针对特殊设计领域，必须能够应用于整个设计流程当中与其他工具互相整合。

有效率的研发团队必须扬弃过去的做法，选择以系统层级设计(System Level Design)为主轴的共同设计媒介。让各领域的工程师们能够在相同的环境下，用各自熟悉的技术语言来表达想法，同时又能够与其他领域、不同设计时间的工程师共享。本文主旨即在介绍这样一个能够「一以贯之」的控制系统设计、发展平台。

Model-Based概念

Mathworks公司搭配了众多任务具箱的Matlab与采用可视化图形区块(Visual block-diagram)设计概念的Simulink等相关工具软件，长久以来一直被广泛的应用在控制系统算法(Algorithm)的设计、仿真与分析上。Simulink的图形区块接口不但可以用来设计算法，同时也可以用来仿真实际受控系统的动态反应特性。以(图一)为例，Fuel rate controller为算法模型，而engine gas dynamics则为受控体动态模型(Plant Dynamic Model)。

《图一 引擎燃油控制系统模型》

在Matlab/Simulink的环境下，每一个模型皆可分别建立、单独执行，而各个模型由于都是在相同的环境下发展出来的，所以整合的问题几乎不存在。这种把将控制系统算法、受控体动态模型模块化的发展环境统称为Model-Based 技术平台。

近年来Stateflow的推出，更是大幅提升了Model-Based环境在算法开发上的时效，也因此Maltab/Simulink/Stateflow环境已成为控制系统算法开发的标准软件。基本上，Stateflow弥补了传统上Matlab/ Simulink在事件驱动(event driven)与诸如：if、while及状态逻辑判断等功能之不足。以下举一例介绍Stateflow如何在Simulink环境底下进行系统开/关电源的处理仿真程序。

(图二)的范例由正弦讯号源(Sine Source Block)、Switch与Stateflow chart所构成。其中正弦讯号仿真传感器讯号输入，而当Switch由0切换到1时，会产生一个正缘触发(rising edge trigger)讯号，我们可以把这个正缘触发讯号定义成Switch_On事件，当然Switch由1切换到0时的负缘触发(falling edge trigger)讯号，便定义成Switch_Off。不过Simulink中正弦讯号、开关与示波器在这个范例里只是当成验证控制策略的工具，Stateflow chart才是范例中整个算法的核心。首先可以看到在Stateflow chart里定义了以下两个事件驱动型态的控制指令：

《图二 StateFlow模型》

On Switch_On:Go_PowerOn；(Switch_On，执行Go_PowerOn)

On Switch_Off:Go_PowerOff；(Switch_Off，执行Go_PowerOff)

起初系统处于电源关闭状态(PoweOffState)，电源开启瞬间，系统侦测到Switch_On后，算法开始执行Go_PowerOn的动作，如果此时输入讯号(data_In)小于或等于0.5，则系统进入PowerOn_2状态，并执行此状态下所定义的程序(data_Out=data_In*5)。而如果输入讯号大于0.5的话则进入PowerOn_1状态，并处理相关程序。一旦有Switch_Off动作产生，系统会自动从Power On状态回到PowerOffState。

当然这个范例本身没有太大的用途，不过我们却可以由此了解结合Simulink可视化图形区块与Stateflow描述式语言的环境，是一个极佳的算法设计与发展平台。工程师可以使用系统层级设计(System level design)的概念，利用可视化图形区块组合与高阶描述语言，快速而有效的设计并验证远较过去复杂的控制策略与算法。

快速原型化(Rapid Prototyping)与HIL( Hardware in the loop)

虽然在Matlab/Simulink的环境下可以用不同的讯号仿真区块，进行算法的设计与验证，不过它不是一个实时(Real Time)的环境。如果能够把在Simulink环境下建立的模型以实时的方式执行的话，算法可以更精确的被验证。在Window的环境底下，算法(尤其是复杂的算法)的执行很难做到真正的实时。可是如果可以把算法转换成C-程序代码，经过编译后放到计算功能较强且有自己实时核心操作系统(Real Time Kernel OS)的硬件上，同时透过适当的I/O与时序规划，便有可能在执行算法模型运算时做到真正的实时。在这种作业环境下工程师可以将设计完成的算法以实时的方式对实际受控体进行仿真测试，这种方式即称为快速原型化测试(Rapid Prototyping Test)(图三)。

《图三 快速原型化作业平台示意图》

Real Time Workshop(RTW)与Stateflow Coder便是植基于这种思维逻辑下的两种工具。RTW与Stateflow Cdoer能够分别把Simulink的图形区块与Stateflow描述语言转换成ANSI C-程序代码，工程师可以把所得到的C-程序代码经过编译后放到特定的硬件(实时系统)里面，以实时方式进行控制器的快速原型化测试。

如果放到实时系统里面的是仿真实际受控系统的动态反应模型，则该实时系统便可以实时的方式仿真受控体反应，这种概念可以被用来执行控制系统软、硬件之整合测试，这种测试方式便称为Hardware in the loop(HIL)(图四)。

《图四 HIL作业平台示意图》

不管是测试软件算法所使用的快速原型化或者是HIL技术，所使用的工具(实时系统)与作业环境几乎完全相同，这种特性可以有效的省去以往许多整合上的问题。在Model-Based技术平台领域里，较著名的实时系统(环境)有：Mathworks的Real Time Window Target与xPC Target、加拿大LSP的SignalMaster、德国的dSPACE与美国Applied Dynamics的RTS。

Model To Chip

能够利用Matlab/Simulink/Stateflow的整合式环境来设计算法，并使用实时系统验证算法，对于算法设计团队而言是的确一个好消息。不过随之而来的问题是：虽然算法开发工程师可以在很短的时间内，发展出许多复杂的控制策略，然而这些复杂算法，往往会因为种种障碍或限制而没有办法完全的实现在最后的产品上。

传统的控制系统开发是由一连串分离的设计时间所组成的，其中包括：客户需求分析、规格定义、算法设计与发展(Algorithm Design)、制订程序流程图(flow chart)、程序编码(Coding)、软件测试以及最后的软硬件整合测试与验证。对于大部分的大型项目而言，前述设计程序通常是由不同的工程团队各自进行的，当设计周期拉的很长时，各领域、各阶段的设计工程师当然想暂时抛却整合性与测试的问题，只想在自己的领域里作独立、优化的设计。因此，无论是算法、系统流程图、程序编码语言的选用，工程师们都会选择在特定设计领域里，能够达成优化结果的工具。而这种工具的特定性，形成了工作团队间的沟通障碍。不但工程师们鲜少彼此分享其概念，各阶段不同工具间转译所造成的错误更是不胜其扰，就算是研发团队完成符合各自规格的设计，也无法确保整合时的正确性与兼容性，整合各团队设计所耗费的时间可能高达整个设计流程的70%以上，减少了创新智能财产的时间。当然，项目规模越大控制策略越复杂，工程团队间所面临的整合困难度也越大。

以PID控制器的程序编码为例，算法是否能够在项目规定的执行期限内完全实现？与软件编码工程师所选择的编码语言有极大的关连。如果只讲求程序执行效率，选择用汇编语言进行控制器程序的软件编码，除了对编码工程师是个挑战之外，流程图的制订、编码、测试、除错及后续维护，都必须消耗一定的项目资源，即使选择以C语言编码，工程规模都不算小。

因此有许多产品开发项目，纵使已经发展出较佳的控制算法，但在编码能力与上市日期的压力下，往往不敢将这些较先进的控制策略，应用在其产品上，致使失去达成产品优化的宝贵契机，导致市场竞争力减弱。

于是大家开始思索一个问题，是不是能够把在Model-Based环境下发展完成之算法模型，直接放到微控制器(MCU)芯片(chip)或者是DSP里面？这样就可以省去制订流程图、程序编码及程序除错等耗费人力与时间资源等工作。而这其中的关键便在于RTW自动编码的程序代码效率。过去的这种由模型转换成程序代码的自动编码效率，在程序的大小与执行速度均不若人工编码。不过随着RTW与Stateflow Coder的不断改良，这种情况已经全然改观，现在的编码效率不但已经可以和人工编码互相比拟，未来在整体效率方面甚至将超过人工编码(图五)。

《图五 RTW自动编码效率发展趋势图》

事实上，在国外已经有许多公司已经将自动编码技术导入其量产控制器的开发项目里，以日本TOYOTA为例，其在 1998 年在市场上推出的复合动力车(Hybrid Vehicle)Prius所使用的控制器即是采用自动编码所产生的C程序代码。

钛思公司也已经开始将此技术应用在：8051、AMD 188与DSP等不同领域芯片的嵌入式程序代码(Embedded code)开发，相信在未来日益广泛而复杂的整合式IC设计与上市时间的压缩下，这套开发技术在控制器开发领域上势必扮演主导地位。

结语

使用「一以贯之」的平台已是控制系统开发的共通趋势，而Matlab/Simulink/Stateflow所提供的Model-Based环境已成为此种平台的代表。Model-Based作业平台为控制系统软件的开发带来了新的概念，在这种平台下，控制系统软件的开发流程可以简化成(图六)的四个步骤，除了有效的节省开算法发时间外，更减少了制订流程图、程序编码及程序除错等耗费人力资源的工作。这种作业平台在未来日益广泛而复杂的整合式IC设计与上市时间缩短的压力下势必扮演主导地位。

《图六 Model-Based技术平台控制系统软件的开发流程》