model-free和model-based的区别

1、企业MBD规范化管理； 2、提供专业信息浏览工具； 3、零组件健康检测； 4、零组件对比； 5、信息更改管理； 6、全息轻量化模型处理； 7、模型清单功能； 8、超级搜索； 9、场景管理。

机电产品的复杂程度越来越高，为缩短研发周期、降低成本，工程师需在设计早期综合考虑产品的一维模型、三维模型、控制模型等，在概念阶段对复杂产品的架构进行验证和优化，并能够在研发早期发现和解决机-电-液-控系统设计中的问题。基于模型的系统工程的解决方案，为复杂产品的研制提供了一个模型驱动的系统工程工作环境，从需求阶段开始即通过模型（而非文档）的不断演化、迭代实现产品的设计，为各方提供一个公共、通用、无二义性的设计信息交流平台。通过模型的结构化定义可在设计初期清晰刻画产品架构、功能与行为等各方面的需求，并通过仿真测试对设计方案进行验证和优化。

集成式MBD开发方式

把FOC算法模型嵌入代码

写在最后

姗姗来迟的第五期（天太冷了，搭模型、写文章也需要毅力）。

本期将是2021年的收官，也将是MBD实战之电机控制系列的最后一期。这一期将介绍如何将模型生成的代码集成到已有的代码中去——把算法模型嵌入你的代码之中去。

1 集成式的MBD开发方式

这个话题这前面的文章中提过了很多次，之所以频繁的提及这种集成的方法，是因为这是目前MBD（Model-Based Design，基于模型的设计）的主流开发方式。

具体而言，集成式MBD的开发方法是：软件代码手写一部分，模型生成一部分，然后再将两部分集成在一起，从而实现完整的软件开发。

手写代码和模型生成有着不同的分工：

手写代码：适用于底层驱动、外设初始化、内存管理、中断管理、OS、Bootloader、协议栈等，还包括片外扩展IC的初始化，以及其他数学特征不明显的功能；

模型生成：适用于数学算法、状态机、数据处理等。

Tips：为了便于区分，本文将手写的代码称为底层代码，而模型生成的代码称为模型代码。底层代码负责的模块并不一定全部都是必须的，例如OS（嵌入式中一般使用实时操作系统，比如FreeRTOS），很多控制可能不需要OS，只需要中断管理即可。

可以看出，底层代码负责的功能，并不适合使用模型来实现。上一期给出的完全由模型实现的电机控制框架，虽然实现了电机控制，但实际上忽略了很多实际项目中必须的模块，例如OS、Bootloader等，还有很多安全机制也没有考虑。

底层代码功能理论上也能通过模型来实现，但没必要、也不需要用模型的方式来实现。MathWorks官方也一直推荐仅使用Simulink/MATLAB搭建算法模型，像底层驱动、内存管理、OS、Bootloader、协议栈等等，还是通过手写代码的方式更为高效。

这一点我有直接咨询过MathWorks的工程师，他告诉我底层代码要通过模型来实现，其难点在于TLC语言的复杂性和硬件芯片的多样性（市面上的芯片太多，每一个都需要适配），这两点没有专业的团队，很难实现模型的高效性。

Tips：我有了解到，有的公司利用StateFlow实现了类似于OS的Task Manager，用于管理模型中的不同任务。其构成也是相当复杂，没有专门的团队是没办法开发和维护的。但也仅限于任务调度——我感觉像复杂的状态机，OS的很多功能是没办法用StateFlow实现的。

对于有复杂算法的软件，MBD代码生成就可以大显身手了，算法越复杂，优势就越显著。举一些例子，如：电机控制、电池管理系统（BMS）、路径规划、紧急制动（AEB）、自动泊车（APS）等算法，其算法实现都可以通过MBD的方式来开发。

用MBD来开发算法，简单总结有如下优势：

便于算法实现和调整：这里指的并不是找Bug，算法的数学表达可能是固定的，但在特定的应用场景下，算法的局部需要特定调整，例如添加状态机实现不同状态的切换。借助模型的图形化，以及MATLAB/Simulink上的各种工具箱，这种调整是很直观，并且很容易实现。

专注算法且算法独立：使用模型搭建算法，我们只需要专注算法实现的本身，不需要考虑底层驱动等因素；由于不考虑底层驱动，算法模型可以方便地实现移植。有人说算法的核心是数学，写代码往往并不太容易兼顾数学，但搭建模型可以。

便利的仿真测试：算法的测试对于优化算法是非常强有力的途径，通过MBD，可以方便的实现MIL、SIL、PIL和HIL，根据测试结果，反馈到模型中，再对模型进行调整，这其中的效率是手写代码无法比拟的。

我自己是有完全手写代码实现电机控制软件所有环节的经验的，对比搭建MBD电机控制框架的开发过程，上述优点是非常明显的，我深有体会。这些优点对新手入门也是非常友好，特别是对非电子、计算机专业的人来说。

在使用集成式MBD开发项目时，软件实现一般需要两个角色：

底层工程师：底层工程师需要对MCU和硬件电路设计很熟悉，他负责实现底层驱动、MCU初始化、OS、Bootloader、协议栈等。他使用手写代码的方式进行开发，在底层代码中给算法预留好接口，以供算法集成。

算法模型工程师：算法模型工程师则负责搭建模型、测试算法，测试通过后就可以生成代码，然后集成到底层代码中去。

Tips：软件实现还可以有一个统筹底层代码和模型代码的架构工程师，给底层和模型设计需求；非软件的部分，一般有一位硬件工程师。

集成好了之后可能还需要进行测试，因为仿真毕竟和实际情况有差异。这时候再调整模型，或者调整底层代码，就可以做到彼此独立、互不干扰了。这一点在传统的开发中往往是一大痛点，而MBD可以很好的解决这个问题。

2 把FOC算法模型嵌入代码

依然以PMSM无感电机控制软件开发为例来介绍如何实现模型代码的集成，硬件平台是NXP的电机开发套件MCSPTE1AK144。

电机开发套件MCSPTE1AK144 - From NXP

后文中提到的最新的模型和代码已经更新到了我的GitHub仓库中，下载模型可以访问下面这个链接：

GitHub仓库：autoMBD电机控制项目

https://github.com/TkungAI/autoMBD_Motor_Control

也可以在私信作者发送关键词“MBD电机控制”，作者还有其他资源，发送关键词“资源”可以收到下载链接。

回到正题，如何开展集成式MBD开发，有以下三个工作环节：

1. 实现算法模型

首先要明确算法模型的需求，可以简单地概括为：

算法的输入和输出是什么？

算法的内部变量有哪些？

算法要处理什么任务（状态机）？

这三个问题的解答也需要和底层工程师和硬件工程师一起协商、相互约束、相互补充，共同明确需求。下图是本次实现的电机控制算法模型（文件名FOC_Ctrl_CodeModel.slx）：

PMSM无感电机控制算法模型 - From autoMBD

PMSM无感电机控制算法模型

-

From autoMBD

这里给出我在本次的PMSM无感电机控制软件开发中，对上述三个问题的回答：

输入和输出

输入为5个ADC采样信号和2个电机控制信号，ADC采用数据用于FOC算法、目标转速的输入，电机控制信号用于控制电机的启停；输出为三相占空比Duty Cycle和LED信号，分别用来执行控制和显示控制状态（参见上图）。

中间变量

中间量不会输出，是在算法处理数据过程中产生的，可以体系算法的特征，比如处理后的电压信号、电流信号、无感算法估计的速度和位置、控制信号等。这部分通过Bus数据对象实现对数据结构体的定义。下图中的varFOC即包含了所有的中间量。

中间变量和StateFlow Chart - From autoMBD

状态机设计

这部分也就是明确电机控制软件具有的功能、任务。在不同的阶段，算法执行的内容是不一样的，例如关闭电机的状态下，不需要跑FOC算法。本次项目中，只实现了简单启动、关闭和故障清楚的功能，状态相对简单，如下图所示：

算法模型状态机 - From autoMBD

Tips：如果有看之前提出的电机控制框架模型，应该就能发现这里的状态机与之非常相似。实际上这里的状态机是对原版的更新和优化，把函数调用方式从Function Call换成了Simulink Function，在Chart内部即可调用函数，不需要把调用的函数模型建立在Chart外面了。具体状态机的讲解可以参考电机实战的03期和04期的内容。

要注意的是，在Run状态下，调用的FOC核心算法模型，其包含了独属于FOC算法的子状态机和中间变量FocInternalPara。这里将FOC算法部分和与非FOC算法部分进行了分别设计，增加算法的灵活性和移植性。

FOC核心数学算法 - From autoMBD

FOC核心算法模型子状态机 - From autoMBD

Tips：该状态机只负责FOC算法的状态控制，包括对齐、开环、追踪和无感闭环四个状态，具体内容可以参考电机实战的04期的内容。

算法模型的内容就介绍到这里，其他的细节还请下载模型后打开查看。模型创建好了就可以生成代码了：

算法模型生成代码 - From autoMBD

这里生成的代码即集成时需要用到的代码。生成代码文件很多，其实是可以优化减少的，后续再开新的文章来讲解如何优化生成的代码。

2. 实现底层代码

Tips：底层代码的实现本质上就是手写代码的开发方式，只不过不做算法部分而已，所以需要有一定的编程基础。网络上有很多嵌入式开发的文章和案例，autoMBD的目标也不是介绍手写代码的开发，所以这里不会很细致的讲如何实现底层代码，仅从方法论的角度简单介绍一下。

可以发现，上述的算法模型中已经没有任何的硬件支持包的模块了，即已经不包含任何的底层驱动、外设初始化等等的功能，这部分由底层代码来实现。

要开发底层代码，需要用到集成开发环境IDE。对于S32K1系列芯片，NXP公司提供了一套免费的、专用于NXP汽车芯片的IDE工具——面向Arm®的S32 Design Studio（简称S32DS）。

面向Arm®的S32 Design Studio - From NXP

打开S32DS后，窗口如下图所示：

S32DS窗口 - From NXP

要配置底层驱动，需要用到S32K1专用图形配置工具——Processor Expert（上图中红色方框中的部分）。该工具能够实现对S32K1系列芯片的灵活配置。而底层驱动则需要使用S32K1 SDK，该SDK具有丰富的API供开发者使用，功能完善且强大。

关于Processor Expert和S32K1 SDK的使用，更多请参考NXP的技术文档。

本次项目中我也实现了一个基本的PMSM无感电机控制的底层代码，包括外设配置、MCU初始化和中断管理的内容，该DS工程位于仓库的这个位置：

S32DS_Prjct ->FOC_Ctrl_MBD_Integration。

该底层代码实现的功能与上一期中的电机控制框架基本一致。

3. 模型代码的集成

到这里，模型代码和底层代码都已经实现，如何集成呢？实际上生成的代码中有一个ert_main.c的文件就给出了集成的实例，读者可以参考该文件。

模型代码集成的过程是比较简单的，主要分为以下几步：

模型初始化：FOC_Ctrl_CodeModel_initialize()

周期性运算Step函数：FOC_Ctrl_CodeModel_step()或rt_OneStep()

终止（如果需要）：FOC_Ctrl_CodeModel_terminate()

Tips：调用并运行模型算法的是Step函数，即计算模型的一个步长。两个Step函数功能是一样的，rt_OneStep()在”模型Step“的基础上封装了一层错误检查，但该错误检查基本上起不了什么作用。

特别要注意的是周期性调用Step函数的周期，需要和算法的运算周期保持一致，不然可能会出现错误结果。

本次项目中，模型初始化在MCU初始化完成后调用；Step函数的调用在Motor_ISR中；模型算法不会终止，所以不需要Terminate函数。

初始化的具体代码如下：

MCU_Init()GD3000_Init()FMSTR_Init() FOC_Ctrl_CodeModel_initialize()MCU_Start() while(1) { FMSTR_Poll()mainCnt++}

Motor_ISR：

void Motor_ISR (void) { ADC_DRV_GetChanResult(INST_ADCONV1, 0, &adcResult[0][0]) ADC_DRV_GetChanResult(INST_ADCONV1, 1, &adcResult[0][1]) ADC_DRV_GetChanResult(INST_ADCONV1, 2, &adcResult[0][2]) ADC_DRV_GetChanResult(INST_ADCONV1, 3, &adcResult[0][3]) ADC_DRV_GetChanResult(INST_ADCONV2, 0, &adcResult[1][0]) ADC_DRV_GetChanResult(INST_ADCONV2, 1, &adcResult[1][1]) ADC_DRV_GetChanResult(INST_ADCONV2, 2, &adcResult[1][2]) ADC_DRV_GetChanResult(INST_ADCONV2, 3, &adcResult[1][3]) FOC_Ctrl_CodeModel_U.ADCinput[0] = adcResult[0][2]FOC_Ctrl_CodeModel_U.ADCinput[1] = adcResult[1][2]FOC_Ctrl_CodeModel_U.ADCinput[2] = adcResult[1][3]FOC_Ctrl_CodeModel_U.ADCinput[3] = adcResult[1][1]FOC_Ctrl_CodeModel_U.ADCinput[4] = adcResult[0][1]FOC_Ctrl_CodeModel_U.FaultSwitch = faultSwitchFOC_Ctrl_CodeModel_U.MotorSwitch = motorSwitch rt_OneStep() pwmDuty[0] = (uint16_t)(FULL_DUTY * FOC_Ctrl_CodeModel_Y.DUTY[0])pwmDuty[1] = (uint16_t)(FULL_DUTY * FOC_Ctrl_CodeModel_Y.DUTY[1])pwmDuty[2] = (uint16_t)(FULL_DUTY * FOC_Ctrl_CodeModel_Y.DUTY[2]) FTM_DRV_FastUpdatePwmChannels(INST_FLEXTIMER_PWM1, 3, pwmChannels, pwmDuty, true) FTM_DRV_ClearStatusFlags(3, FTM_TIME_OVER_FLOW_FLAG|FTM_RELOAD_FLAG)}

可以看到模型的传参和返回结果是通过全局变量的方式实现的：

输入全局变量：FOC_Ctrl_CodeModel_U

输出全局变量：FOC_Ctrl_CodeModel_Y

这里是可以通过对算法模型进行设置的，可以改成传参的方式，本次项目使用的是默认方式。

前文中的算法模型的中间变量也是一个全局变量：

模型中间变量：FOC_Ctrl_CodeModel_DW.varFOC

到这里模型代码的集成就算完成了，可以像手写代码的方式调试和下载代码了。

其实还有很多关于代码集成的细节和技巧没有提到，本次项目实现的模型代码完全是在默认设置下生成的。

Simulink是可以对生成的代码进行很细致的控制的，例如控制代码生成的位置、函数传参的方式、函数的复用等，还有代码如何优化，如何创建数据字典来管理模型数据。关于这些技巧和实践，我会在后续的文章中进行介绍，欢迎持续关注作者。

3 写在最后

先说一点题外话，我最近才了解到NXP新发布的S32K3系列芯片，其最新的硬件支持包MBDT有了一个较大的升级，它的底层模块已经实现了完全等同于S32K3专用底层配置工具的功能。这一升级使得底层驱动这一功能也可以在Simulink模型中实现。

现在的S32K1的MBDT底层模块由于功能很有限，很多情况下底层驱动的配置必须使用专用配置工具Processor Expert来配置才能满足需求。而S32K3的更新有望改变这一现状，有兴趣的可以了解一下S32K3芯片和它最新的硬件支持包MBDT。

S32K3X4EVB-Q172 - From NXP

到本篇文章为止，我认为关于MBD的基础部分，应该已经写得差不多了，如果看完我的全部文章，应该能有所收获。

下一期我将对所有发布的文章，和GitHub仓库进行一次清理和总结。

明年autoMBD将会进入到下一个阶段，会尝试更有挑战的内容，例如TLC语言、MBD实现通信、MBD与OS的结合等。所以请持续关注autoMBD，更多技术分享不容错过。

2021年还剩下最后一周，在这里提前祝大家2022年新年快乐，希望各位读者能在2022年收获更多！

Simulink是一个对动态系统（包括连续系统、离散系统和混合系统）进行建模、仿真和综合分析的集成软件包，是Matlab的重要组成部分。

总结一下Simulink建模与仿真步骤：

画出系统框图，将需仿真的系统根据功能划分为子系统，然后选用模块搭建每个子系统

2. 拖拽模块库中所需模块到空白模型窗口中，按系统框图的布局摆好并连接各模块

3. 若系统比较复杂，可将同一功能模块封装成一个子系统

4. 设置各模块的参数和仿真有关的各种参数

5. 保存模型，运行仿真，观察结果

6. 调试并修改模型，直到结果符合要求为止

拓展资料：

Simulink是MATLAB中的一种可视化仿真工具， 是一种基于MATLAB的框图设计环境，是实现动态系统建模、仿真和分析的一个软件包，被广泛应用于线性系统、非线性系统、数字控制及数字信号处理的建模和仿真中。

Simulink提供一个动态系统建模、仿真和综合分析的集成环境。在该环境中，无需大量书写程序，而只需要通过简单直观的鼠标操作，就可构造出复杂的系统。

参考资料：百度百科—SIMULINK

一、概述

    MBT中文名称为基于模型的测试,基于模型的测试属于软件测试领域的一种测试方法。

二、背景

      软件测试是一款软件产品质量的最后一道防线，是产品线上前必不可少的、最重要的一环。每一款高质量的软件产品背后，都蕴含了大量的测试工作。而且测试工作很可能是软件开发过程中最昂贵、劳动最密集的工作。在设计测试用例的过程中，或多或少的存在着问题，使得软件测试结果不那么理想。下面引入新的测试方法，基本模型的测试，是自动化测试的一个分支，它将测试用例的设计依托于被测系统的模型，并基于该模型自动生成测试用例的技术。从质量保证的角度来看，我们可以制定测试的内容，但是无法保证测试会覆盖所有可能的组合，而MBT则允许软件开发和测试人员，只关注建立系统的正确性及模型的规范性，再通过专门的MBT工具根据不同的测试用例设计策略从系统模型生成可靠的测试用例。

    与传统测试相比，优点：

         （1）测试用例的维护更轻松：维护好模型，无需关注测试用例的细节

         （2）软件缺陷发现的更早：在构建被测系统模型的过程中，需要对被测系统有比较全面的理解，那么在早期建模过程中就可以发现被测系统中的一些问题，不需要等到执行大量用例时才发现；

         （3）测试自动化的水平更高：建模后，MBT可以自动生成测试用例，不需要人工编写测试文档；

         （4）测试覆盖率变得更高，使得彻底的测试（即：穷尽测试）成为可能：传统测试设计的过程中依赖人工，MBT生成测试路径时会避免人工设计测试用例时的思维局限性，生成更丰富的测试路径用例，但是是否需要执行“彻底”的测试由漏测对业务的影响决定。MBT只是从技术上提供了穷尽测试可能性。

         （5）基于模型间接维护测试用例的方式更高效：传统维护时需要依赖人工，需要耗费大量的人力和时间成本，重新测试设计。使用MBT只需要维护好测试模型即可，生成测试用例的工作可以由MBT工具自动完成；

     缺点，即未广泛推广的原因：

         （1）学习成本较高：要求开发人员、测试人员都精通建模，和工具的选型；

         （2）使用MBT的初期投资较大：已有的MBT工具不一定适合自己产品，定制的话需要考虑扩展性，和处理复杂逻辑，也就是要花费大量时间和精力；

         （3）用例爆炸

   总结下，测试方法多种多样，MBT和传统测试相比，各有优劣。如果一个应用的任何组件都可以通过模型来模拟、通过驱动程序来驱动，并可以通过测试结果来比较的话，那么这个应用是MBT的最佳候选者。

   2.1  通用流程

 2.2  Model design （模型设计）

  模型设计，目的是用来为构造测试用例而进行的被测系统描述

（1）模型关注点：

     （2） MBT模型分类：

2.3  Tests selection （ 测试需求选择）

             指导测试用例生成器（ test generation）如何生成用例

2.4   Tests  paths generation（测试用例生成）

           按模型及测试需求选择来生成测试用例。GraphWalker就是完成这部分工作的一个开源的java工具。

2.5   Tests execution（执行测试）

           执行测试，并比较预期

2.6  FSM举例：海拍客mallpc 登录相关功能建模，如下

一个箭头，代表一次测试动作；

一个节点，代表一次测试验证；

2.7 常见工具 ：BPM-X、fMBT、GraphWalker

三 、GraphWalker简介

 

 GraphWalker就是一个基于测试模型的用例生成工具，主要支持于FSM, EFSM模型。它以有向图的形式读取模型，生成测试路径，适合于多状态以及基于事件驱动的状态转换的系统。

四、使用GraphWalker建模

有向图中，顶点（或节点）表示一些期望的状态，并且边（弧，箭头，过渡）表示为了实现期望的状态需要做的任何动作；

 4.1 建模工具：yEd

4.2 建模规则1

      4.3 建模规则2

    4.4 建模keywords

4.5 支持多模型：

     GraphWalker可以在一个会话中使用几个模型。这意味着在生成路径时，GraphWalker可以选择跳出一个模型到另一个模型。当将不同的功能分为多个模型时，这是非常方便的。

     

多模型offilne运行举例：

java -jar graphwalker-cli-4.0.0-SNAPSHOT.jar -d all offline -m Model_A.graphml random(edge_coverage(100)) -m Model_B.graphml random(edge_coverage(100)) -m Model_C.graphml random(edge_coverage(100)) -m Model_D.graphml random(edge_coverage(100)) –o

当路径生成到达模型A中的顶点v_B时，它必须考虑关键字SHARED：B ..这将告诉GraphWalker使用相同的名称搜索所有其他模型的同一个关键字：B.在我们的例子中，只有一个，它在模型B中。

现在GraphWalker决定是跳出模型A，进入模型B中的顶点v_B，还是留在模型A中。这个决定是基于随机的。

多模型特性：

五、路径生成器和结束条件

六、GraphWalker工作方式

以作为第三方库为例： 使用GraphWalker第三方库实现模型自动化测试

七、GraphWalker命令行：此处省略

八、Restful或WebSocket服务的区别：此处省略

九、Web Socket API接口：此处省略

十、REST API接口：此处省略

十一、GraphWalker源码：

GraphWalker工具核心：graphwalker-core

参考资料：官网 http://graphwalker.github.io/

备注：

FSM ：有限状态机 Finite State Machine

EFSM：扩展有限状态机

因为Simulink是MATLAB最重要的组件之一

它提供一个动态系统建模、仿真和综合分析的集成环境。在该环境中，无需大量书写程序，而只需要通过简单直观的鼠标操作，就可构造出复杂的系统。Simulink具有适应面广、结构和流程清晰及仿真精细、贴近实际、效率高、灵活等优点，并基于以上优点Simulink已被广泛应用于控制理论和数字信号处理的复杂仿真和设计。同时有大量的第三方软件和硬件可应用于或被要求应用于Simulink。 Simulink是MATLAB中的一种可视化仿真工具， 是一种基于MATLAB的框图设计环境，是实现动态系统建模、仿真和分析的一个软件包，被广泛应用于线性系统、非线性系统、数字控制及数字信号处理的建模和仿真中。Simulink可以用连续采样时间、离散采样时间或两种混合的采样时间进行建模，它也支持多速率系统，也就是系统中的不同部分具有不同的采样速率。为了创建动态系统模型，Simulink提供了一个建立模型方块图的图形用户接口(GUI) ，这个创建过程只需单击和拖动鼠标操作就能完成，它提供了一种更快捷、直接明了的方式，而且用户可以立即看到系统的仿真结果。 Simulink是用于动态系统和嵌入式系统的多领域仿真和基于模型的设计工具。对各种时变系统，包括通讯、控制、信号处理、视频处理和图像处理系统，Simulink提供了交互式图形化环境和可定制模块库来对其进行设计、仿真、执行和测试。. 构架在Simulink基础之上的其他产品扩展了Simulink多领域建模功能，也提供了用于设计、执行、验证和确认任务的相应工具。Simulink与MATLAB紧密集成，可以直接访问MATLAB大量的工具来进行算法研发、仿真的分析和可视化、批处理脚本的创建、建模环境的定制以及信号参数和测试数据的定义。

simulink一直正在创建模型：可以重装，不能解决，需要换个matlab版本。Simulink是美国Mathworks公司推出的MATLAB中的一种可视化仿真工具。Simulink是一个模块图环境，用于多域仿真以及基于模型的设计。它支持系统设计、仿真、自动代码生成以及嵌入式系统的连续测试和验证。Simulink提供图形编辑器、可自定义的模块库以及求解器，能够进行动态系统建模和仿真。

simulink过于强大，我这个新手接触的是汽车控制器的设计。具体是这么使用simulink的：基于模型设计的方式设计建立控制器的simulink模型（包含油门、刹车踏板信号采集，滤波，扭矩输出控制等控制策略）；建立道路工况、汽车机构等simulink模型，让控制器的模型和刚才的模型在电脑里面仿真（这叫离线仿真）。然后将优化后的控制器simulink模型下载到如DSPACE中，进行硬件在环仿真或实时仿真，最后验证后把控制器模型用simulink的RTW模块库转换成C代码，并编写底层驱动程序，写入单片机。设计硬件和外围电路，就成了一个完整的汽车控制器。如ECU。当然其中还要标定数据

结合区位论、空间插值、智能空间推理等知识，多层次渐进式空间采样网络体系主要包括多层次渐进式空间采样网络框架设计、最优样本量获取、采样样点布设等几个方面。

( 一) 多层次渐进式空间采样网络框架设计

当前空间采样网络设计主要包括基于模型的方法和基于设计的方法。基于模型的方法主要采用统计学中采样模型、优化模型等，运用采样网络设计规则 ( 包括克里金方差最小原则、WM 原则等) 自动生成采样网络基于设计的方法则主要依据专家对研究区域的先验知识，人工布设采样样点形成采样网络。两种方法均存在一定的不足，基于模型的方法存在一定的不稳定性，基于设计的方法则受专家主观意识的影响。基于此，本研究提出多层次渐进式空间采样网络框架设计技术，集合了基于模型方法和基于设计方法各自的优点，旨在消除采样网络设计过程中客观不确定性和主观不一致性的影响，使得采样网络客观反映研究区的区域特征，提高采样和监测精度。

多层次渐进式空间采样网络框架设计技术充分考虑了研究区存在监测样点布局和不存在监测样点布局两种情况，首先基于采样模型自动计算最优样本量并完成样点布设，然后根据专家的先验知识以及空间采样数据对采样网络进行优化，剔除异常点，从而提高采样精度和效率。

( 二) 最优样本量获取

在总体中抽出一定量的样本，用所抽样本的均值与方差能较好地估计总体的均值与方差，即抽取样本的均值具有足够的精度和较大概率近似于总体均值。

当所研究的属性在统计学上具有正态分布特征时，可构造统计量公式，在专家指导下( 包括专家对于研究区的先验知识和预采样数据等) 推导出采样需要置信限下的合理采样数:

退化废弃地遥感信息提取研究

式中:η为采样精度μ为总体均值σ为标准差xn为第n个采样点。

上述样本量为指定采样精度下的最小样本量，从而既保证了采样精度，又提高了采样效率。

(三)采样样点布设

传统的空间采样网络设计较多依靠专家对研究区以及监测指标的先验知识，按着一定的布点方法人工确定样点布局，常用的布点方法包括功能区布点法和几何图形布点法，其中几何图形布点法包括网格布点法、同心圆布点法和扇形布点法。随着抽样理论和地统计学理论的发展，简单随机抽样模型、系统抽样模型和分层抽样模型等抽样模型被广泛应用。

1.简单随机抽样

简单随机抽样是指从总体N个单位中任意抽取n个单位作为样本，使每个可能的样本被抽中的概率相等。简单随机抽样分为重复抽样和不重复抽样。在重复抽样中，每次抽中的单位仍放回总体，样本中的单位可能不止一次被抽中不重复抽样中，抽中的单位不再放回总体，样本中的单位只能抽中一次。简单随机抽样的具体方法包括抽签法和随机数字表法。

2.系统抽样

系统抽样是纯随机抽样的变种，先将总体从1～N相继编号，并计算抽样距离K=N/n(N为总体单位总数，n为样本容量)，然后在1～K中抽一随机数k1作为样本的第一个单位，接着取k1+K，k1+2K，…，直至抽够n个单位为止。系统抽样要防止周期性偏差，因为其会降低样本的代表性。

3.分层抽样

又称分类抽样或类型抽样，先将总体的单位按某种特征分为若干次级总体(层)，然后再从每一层内进行单纯随机抽样，组成一个样本。将总体划分为若干个同质层，再在各层内随机抽样或系统抽样，分层抽样的特点是将科学分组法与抽样法结合在一起，分组减小了各抽样层变异性的影响，抽样保证了所抽取的样本具有足够的代表性。

分层抽样根据在同质层内抽样的方式不同，又可分为一般分层抽样和分层比例抽样，一般分层抽样是根据样品变异性大小来确定各层的样本容量，变异性大的层多抽样，变异性小的层少抽样，在事先并不知道样品变异性大小的情况下，通常多采用分层比例抽样。

分层抽样比单纯随机抽样所得到的结果准确性更强，组织管理更方便，而且能保证总体中每一层都有个体被抽到。这样除了能估计总体的参数值，还可以分别估计各个层内的情况，因此分层抽样技术常被采用。

将上述模型应用到空间采样领域，通过引入空间相关系数表征样点之间的空间结构性，结合传统采样模型动态计算最优样本量并进行样点布设，通过专家的指导对布设的样点进行优化，从而使样点布局与指标空间结构基本吻合，提高了采样精度。