BEEVA Labs 数据分析师 Ricardo Guerrero Gomez-Ol 在 Medium 上发表了一篇文章，盘点了目前最流行的深度学习框架。为什么要做这一个盘点呢？他写道：「我常听到人们谈论深度学习——我该从哪里开始呢？TensorFlow 是现在最流行的吧？我听说 Caffe 很常用，但会不会太难了？在 BEEVA Labs，我们常常需要应对许多不同的深度学习库，所以我希望能够将我们的发现和感想分享出来，帮助那些刚刚进入深度学习这一美丽世界的人。
1  TensorFlow
对于那些听说过深度学习但还没有太过专门深入的人来说，TensorFlow 是他们最喜欢的深度学习框架，但在这里我要澄清一些事实。 在 TensorFlow 的官网上，它被定义为「一个用于机器智能的开源软件库」，但我觉得应该这么定义：TensorFlow 是一个使用数据流图（data flow graphs）进行数值计算的开源软件库。在这里，他们没有将 TensorFlow 包含在「深度学习框架」范围内，而是和 Theano 一起被包含在「图编译器（graph compilers）」类别中。 在结束了 Udacity 的 Deep Learning 课程（https://www.udacity.com/course/deep-learning–ud730）之后，我的感觉是 TensorFlow 是一个非常好的框架，但是却非常低层。使用 TensorFlow 需要编写大量的代码，你必须一遍又一遍地重新发明轮子。而且我并不是唯一一个这么想的人。Andrej Karpathy 在 Twitter 上就多次吐过槽： 推文：我希望 TensorFlow 能标准化我们的代码，但它是低层面的，所以我们在其上面的层上分道扬镳了：Slim、PrettyTensor、Keras、TFLearn … 比如：我们在 OpenAI 使用 TensorFlow，但我们似乎都更喜欢其它框架，我们有些人还写自定义代码。叹 几个月前，我去参加了「Google Experts Summit: TensorFlow, Machine Learning for everyone, with Sergio Guadarrama」。Sergio 是开发 TensorFlow 的一位工程师，但他在会上没有展示 TensorFlow，而是展示了一个在 TensorFlow 上工作的更高层的库 tf.contrib：https://www.tensorflow.org/tutorials/tflearn/。我的看法是：他们内部已经意识到如果要让更多人使用 TensorFlow，他们就需要以更高的抽象水平在其上创建一些层，从而简化 TensorFlow 的使用。 TensorFlow 支持 Python 和 C++，也允许在 CPU 和 GPU 上的计算分布，甚至支持使用 gRPC 进行水平扩展。 总结：TensorFlow 非常好，但你必须了解它好在哪里。如果你不想什么事都自己手动去做和重新发明轮子，你可以使用更简单的库（安利一下 Keras）。
2  Theano
Theano 是最老牌和最稳定的库之一。据我所知，深度学习库的开端不是 Caffe 就是 Theano。 和 TensorFlow 类似，Theano 是一个比较低层的库。也因此它并不适合深度学习，而更适合数值计算优化。它支持自动的函数梯度计算，带有 Python 接口并集成了 Numpy，这使得它从一开始就成为了通用深度学习领域最常使用的库之一。 今天，Theano 依然效果良好，但由于它不支持多 GPU 和水平扩展，在 TensorFlow 的热潮下（它们针对同一个领域），Theano 已然开始被遗忘了。
3  Keras
「You have just found Keras.」
上面这句话是你打开文档页面时看到的第一句话。我还记得我第一次发现 Keras 的时候。那时候我正在柏林解决 Data Science Retreat 的最后一个项目，为此我努力进入了深度学习库的世界。我在起步时就已经有了足够的深度学习知识，但我没有时间自己手动编写功能，也没有时间探索和学习一个新的库（截止时间不到 2 个月，而我还有课要上）。然后我发现了 Keras。 我真的很喜欢 Keras，因为它的句法是相当明晰的，它的文档也非常好（尽管相对较新），而且它支持我已经掌握的语言 Python。它的使用非常简单轻松；我们也能很直观地了解它的指令、函数和每个模块之间的链接方式。 Keras 是一个非常高层的库，可以工作在 Theano 和 TensorFlow（可以配置）之上。另外，Keras 强调极简主义——你只需几行代码就能构建一个神经网络。在这里你可以比较一下 Keras 和 TensorFlow 实现相同功能时所需的代码。
4  Lasagne
Lasagne 是一个工作在 Theano 之上的库。它的使命是简化一点深度学习算法之下的复杂计算，同时也提供了一个更加友好的接口（也是 Python 的）。这是一个老牌的库，并且很长时间以来它都是一个扩展能力很强的工具；但在我看来，它的发展速度赶不上 Keras。它们的适用领域都差不多，但 Keras 有更好的文档、也更完整。
5  Caffe
Caffe 不只是最老牌的框架之一，而是老牌中的老牌。 在我看来，Caffe 有非常好的特性，但也有一些小缺点。起初的时候它并不是一个通用框架，而仅仅关注计算机视觉，但它具有非常好的通用性。在我们实验室的实验中，CaffeNet 架构的训练时间在 Caffe 中比在 Keras 中（使用了 Theano 后端）少 5 倍。Caffe 的缺点是它不够灵活。如果你想给它来一点新改变，那你就需要使用 C++ 和 CUDA 编程，不过你也可以使用 Python 或 Matlab 接口进行一些小改变。 Caffe 的文档非常贫乏。你需要花大量时间检查代码才能理解它（Xavier 初始化有什么用？Glorot 是什么？） Caffe 的最大缺点之一是它的安装。它需要解决大量的依赖包……我曾经安装过 Caffe 两次，真正痛苦至极。 但要清楚，Caffe 并不是一无是处。在投入了生产的计算机视觉系统的工具上，Caffe 是无可争议的领导者。它非常稳健非常快速。我的建议是：用 Keras 进行实验和测试，然后迁移到 Caffe 中进行生产。
6  DSSTNE
DSSTNE 的发音同 Destiny，是一个酷劲十足的框架却总是被忽略。为什么？除去其他的因素不谈，原因在于这个框架不具有普适性，不是为一般常见任务所设计的。DSSTNE 框架只做一件事——推荐系统，但把这件事做到了极致。既不是为研究而设计，也不是为测试 idea 而设计（来源其官方网站的宣传语），DSSTNE 框架是为量产而设计。 我们已在 BEEVA 上做一些实验测试了，目前我已经感觉到这是一个运行非常快的工具并且能够得到非常好的运行结果（平均准确率均值——mAP 很高）。为了达到这一速度，DSSTNE 框架用 GPU 运行，这也是它的弊端之一：不同于篇中分析的其他框架或者库，这个框架不支持使用者随意在 CPU 和 GPU 中切换，而这可能会对有些尝试有用，但我们在 DSSTNE 里做这样的尝试时是不被框架所允许的。 其他的感受就是迄今为止 DSSTNE 还不是一个足够成熟的项目，而且它封装的太严密了（「black box」）。如果我们想深入了解这个框架的运行机制是什么，我们必须且只能去看它的源码，并且你需要完成很多必须完成的设置（「TODO」）才可以看到。同时，关于这个框架的在线教程不多，而能让开发者进行操作尝试的指导就更少了。我的意见是再等 4 个月看看 DSSTNE 的最新版本。不能不说 DSSTEN 的确是一个很有意思的项目但还需要一点成长空间。 还想说明一点，这个框架对编程能力没有要求。DSSTNE 框架通过其终端的命令行来执行相关操作。 到目前为止，很多我知道也很流行的框架和库我还没有用过，我不能给出更多具体的细节。
7  Torch
在这个世界上每天仍有很多战争，但是一个优秀的「勇士」（西班牙语「Guerrero」）必须熟知哪些战争是需要去参加作战的，哪些是可以选择不参与的。 Torch 是一个很著名的框架，因巨头 Facebook 的人工智能研究所用的框架是 Torch，并且在被谷歌收购之前 DeepMind 也是用的 Torch（收购之后 DeepMind 转向了 TensorFlow）。Torch 的编程语言是 Lua，这就是我刚才所谈的「战争」的具体所指。在目前深度学习编程语言绝大部分以 Python 实现为主的大趋势下，一个以 Lua 为编程语言的框架的最大劣势莫过于此。我从未用使用过这个语言，如果我想使用 Torch 这个工具，毫无疑问我需要先学习 Lua 语言然后才能使用 Torch。这固然是一个合理的过程，但就我个人情况来说，我偏向于用 Python、Matlab 或者 C++的实现。
8  MXNet
mxnet 是一个支持大多数编程语言的框架之一，包括 Python，R，C++，Julia 等。但我觉得使用 R 语言的开发者会特别偏爱 mxnet，因为至今为止还是 Python 以不可置疑的态势称霸深度学习语言的（Python 与 R 的对决，猜猜我会站哪边？:-p） 老实说，在此之前我并没有很关注 mxnet。但是当亚马逊 AWS 宣布选择 mxnet 作为其深度学习 AMI 的库时触发我开始关注 mxnet。我必须去了解一下。后来我获知亚马逊把 mxnet 列为其深度学习的参考库并宣称其巨大的横向扩展能力。我感觉到这里面有一些新的改变发生而且我必须深入了解。这也是为什么我们 2017 的 BEEVA 的技术测试名单里有 mnxet 的原因。 我对多 GPU 的扩展能力有点疑虑并且我很原意去了解这样实验的更多细节，但目前我还是对 mxnet 持怀疑态度。
9  DL4J
我接触这一库，是因为它的 documentation。当时我正在寻找受限玻尔兹曼机、自编码器，在 DL4J 中找到了这两个 documentation。里面的文件很清楚，有理论，有代码案例。我必须得说 DL4J 的 documentation 简直是艺术品，其他库在记录代码的时候需要向它学习。 DL4J 背后的公司 Skymind 意识到，虽然在深度学习圈内 Python 是老大，但大部分程序员起自 Java，所以需要找到一个解决方案。DL4J 兼容 JVM，也适用 Java、Clojure 和 Scala，随着 Scala 的起起落落，它也被很多有潜力的创业公司使用，所以我还会继续紧追这个库。 此外，Skymind 的 twitter 账户非常活跃，不断公开最新的科学论文、案例和教程，及其推荐大家关注。
10  Cognitive Toolkit
认知工具包（Cognitive Toolkit）之前被大家所知的缩略是 CNTK，但是最近又重命名回归到 Cognitive Toolkit，很可能是想沾最近微软认知服务（Microsoft Cognitive services）的光。在公开的基准测试上的表现来看，这个工具似乎很强劲，支持纵向和横向的推移。 目前为止，Cognitive Toolkit 似乎不是很流行。我并没有读到很多关于使用这个库的博客、在线实验案例或者在 Kaggle 里的相关评论。但是对我来说，一个背靠微软研究的框架特别强调自己的推移能力让我觉得有些奇怪，毕竟微软研究团队可是在语音识别上打破世界纪录并逼近人类水准。 我在查看他们项目百科的一个范例的时候了解到 Cognitive Toolkit 在 Python 上的语法和 Keras 是非常相类似的（Cognitive Toolkit 也支持 C++），这不禁让我在想（并不是确认）Keras 才是正确的方式。 
总结
我的结论是：如果你想进入这一领域， 你应该首先学习 Python 。尽管这一领域还支持其它很多语言，但 Python 是应用范围最广而且最简单的一个。但是为什么要选择 Python 呢——毕竟 Python 速度这么慢？因为大多数的库都使用的是符号式语言（symbolic language）方法而非命令式语言（imperative language）方法。解释一下也就是说：不是一条接一条地执行你的指令，而是根据你给出的所有指令创建一个计算图（computing graph）。这个图被内部优化和编译成可执行的 C++ 代码。这样你就能同时利用上两个世界的最优之处：Python 带来的开发速度和 C++ 带来的执行速度。 人们对深度学习的兴趣越来越大了，但人们并不愿意等待算法训练所需的大量计算时间（而且我说的是 GPU，想都不要想只使用 CPU）。这也是多 GPU 支持、多机器上的水平扩展甚至定制硬件最近开始得势的原因。 深度学习领域非常活跃、易变。很可能我现在所说的在 2017 年的中旬就变了 查看全部

本人就职于广州汽车集团乘用车有限公司，公司在工厂建设、设备导入、生产调试期间进行了大量的非标品采购。
非标品包括非标台架、物流器材（台车、脚轮、货架、线棒货架、仓库笼、托盘、规格箱）、工装夹具、非标备件、模具机加工等。
在此本人针对公司非标品采购的现状进行PDCA分析并最终达到成本控制的目的。
一、非标品采购现状
1）采购环节时间较短，申购时间甚至晚于需求时间。
2）在一个很短的时间段内，多个部门分别申购同一物品，各自申购量3、5个不等；要求到货期不一，时间相差2天、5天不等。
3）同一张申购单中申购台架、物流器材、工装夹具等多类别物品。
4）部分项目采购部定厂定价时间长达2个月。
二、采购理想状态
1）需求应有预算、有计划、优选精简规格、集中维护、定额管理—统筹控制。
2）供应商择优选择、优化整合，培育建成既有稳定供应渠道又有充分竞争的、可持续改善提高的集中采购体系。
三、目前采购现状与理想状态的差异—问题点
1、申购环节问题点
1）无统筹预算、无统一计划（既没有同部门的统筹，更说不上跨部门统筹）。
2）使用部门在提出采购申请单之前，为了制定预算，进行询价和成本分析，造成申购时间长，而且与采购部工作重复。
3）同一物品在一个短时间间隔内多重申购，申购工作多重重复，造成从担当到各级主管的资源浪费。
4）采购环节时间较短，申购时间甚至晚于需求时间，所以80%申购单为紧急采购。
2、采购环节问题点
1）采购工作量大，采购部门反复分类甄别，穷于应对，采购效率低。
2）零星采购，供应商混乱，优化整合困难，采购价高，至少高于正常市场价20%。
3）同一种物品各部门推荐不同的供应商且不愿意整合，造成供应商管理混乱。
4、真因分析
1）对厂房建设、设备投入了大量的精力调研、考察，最后选定供应商。
而且只有厂房、设备准备充分后，才能对非标品进行规划和设计。这就造成了以上的问题点。

2）工厂建设期需求时间紧急，交货期变成了第一要素。各车间自行进行采购，没有统筹。

3）供应商资源缺乏，没有前期规划，没有充分的调研市场，临时抱佛脚，供应商的选择，变成了供应商服务选择。

4）供应商水平参差不齐，此类供应商较多，每个地区都有很多，在广州地区更多。





5、对策
1）公司统一管理物流器材；各车间或制造领域统一管理非标台架、工装夹具、模具机加工等，一段时间统一购买。
2）根据非标品的分类，提前调研市场，根据技术能力、业绩、售后服务等，筛选出一段时间内的候选供应商，每个类别选择3～4家候选供应商。
3）前期购买时，与几家供应商合作，既可满足交货期的要求，又可通过合作，验证和比较各公司的实力，为以后的购买奠定基础。
4）为了公平公正的原则，针对金额较大的采购项目，在最终报价时，可以选择招投标的方式，要求供应商密封报价，然后公司内部相关部门一起统一拆阅，选择意向供应商。
如果意向供应商的报价有问题，或者偏高，这时可以要求意向供应商再进行一次报价。
5）要求供应商报价时填写“分项报价表”，以达到有理有据的进行成本分析。
成本的组成有：设计费、材料费、外购件费、加工费、利润、管理费、调试费、运输费、增值税等。
运输费为运输费用的合计，应该调研清楚市场上运输收费标准，合理的分摊到每个物品上。
工装夹具、模具机加工涉及调试费用，可以根据业内平均水平计算。
管理费用=（材料费+外购件费+加工费）*管理费率
利润=（材料费+外购件费+加工费）*利润率
未税单价=设计费+材料费+外购件费+加工费+运输费+调试费用+管理费+利润
含税单价=未税单价*增值税率
以上是供应商的报价需填写的分项报价表，同时采购人员也针对这些项目进行分析，与供应商的报价在一张表格中形成对比，通过与供应商磋商，确定最终价格。

6、总结
通过本人的分析，希望大家可以举一反三，在自己的工作领域有针对性的制定改善措施。






来源：如何通过PDCA分析对非标品采购进行成本控制 查看全部

    把软件或系统搬上云的基础平台，如果不做模块，架构，服务，用户管理等调整，这是伪SaaS。
    应用层是运行在云平台层上应用的集合。每一个业务需求都对应一个应用，所以实现特定的业务逻辑，并且通过服务接口与用户交互。软件即服务交付给用户的是定制化的软件应用，也就是指软件提供方根据用户的需求，将软件或应用通过租用的形式提供给用户，继而用户通过网络访问使用。
    对于软件开发者而言，由于与软件相关的所有资源都放在云中，开发者可以方便地进行软件的部署和升级，因而软件产品的生命周期不再突显。开发者甚至可以每天都对软件进行多次升级，而这些操作对于用户而言都是透明的，用户感觉到的只是质量越来越完善的软件服务。
    保护软件即服务知识产权是相当有利的，因为软件的副本本身不会提供给客户，从而减少了反编译等恶意行为发生的可能。
    应用层的基本功能就是要为用户提供尽可能丰富的创新应用，为企业和机构用户将IT流程简化，为个人用户将日常生活简化，实现这些应用的结构和方式也变得十分灵活多变。应用层上运行的软件千变万化，新应用层出不穷，想要定义应用层的基本结构可并不容易。
    在基础架构层，我们把应用分为带宽敏感性应用和数据读写敏感性应用两大类。在云计算架构中我们把应用层分为三大类，第一类是面向大众的标准应用，采用多租户技术，为数量众多的用户提供相互隔离的操作空间。其提供的服务是标准并且一致的。用户除了界面上的个性化设定外，并不具有更为深入的自定义功能，就像是谷歌的Apps。
    标准应用是人们日常生活中不可或缺的服务，类似于文档处理、电子邮件和日程管理等。这些应用提供的功能是人们所熟悉的，绝大多数云应用的使用者将会使用它们来处理一些日常事务。标准应用的类型有限，它们必须具备的功能和与用户交互的方式在一定程度上已经形成了业界标准。
    第二类是为了某个领域的客户而专门开发的客户应用，该类应用开发好标准的功能模块，允许用户进行不限于界面的较为深度定制。不同于标准应用是面向最终用户的立即可用的软件。客户应用一般是针对企业级用户，需要用户进行相对更加复杂的自定义和二次开发。客户应用针对的是具有普遍性的某种需求，比如客户管理系统( CRM)和企业资源规划系统( ERP) 等。这种应用可以替不同的客户定制，受数量较大的用户群使用。Salesforce 的CRM就称得上是成功实例了。
    第三类是由第三方的独立软件开发商在云计算平台层上开发的满足用户多元化需求的应用。而这类云应用一般由独立软件开发商或者是开发团队在公有云平台上搭建，是用以满足用户某一类特定需求的创新型应用。多元应用满足的往往是小部分用户群体的个性化需求。
    就像是Mutiny为旧金山地区的用户提供了地铁和公交的时刻表，The Option Lab为投资者提供了期权交易策略制定、风险分析、收益预期等方案。FitnessChart帮助正在进行健身练习的用户记录体重、脂肪率等数据，这样，用户可以跟踪自己的健身计划，评估健身的效果。
   从移动付费到家庭理财，类似的多元化应用不胜枚举，涉及人们生活的方方面面，满足各种不同人群的各种不同需求。这充分体现云计算应用层的特征，即云应用的理想模式。不论用户身处何处，使用何种终端，只需要有互联网连接和标准的浏览器，便可以不经任何配置从而访问属于自已的应用。这些应用能够通过浏览器访问，又或者具有开放的API，允许用户或者受客户端的调用。在2012年末有7亿的智能手机和终端设备在当今的用户市场将会使得云计算的应用层不断迎来新纪元。
    云应用要求高度的整合，而且云应用之间的整合能力对于云应用的成功无比重要。自然除此之外，用户在使用云服务时，不需要进行先期投入，只需要在使用时也不可忽视按照实际的使用情况付费所产生的敏捷性成本降低的情况。 查看全部

“两会”热点引发多方关注

为何要打造中国的工业软件平台
 
 
 日前，人民日报社《中国经济周刊》与相关单位联合策划的“呼唤中国的工业安卓”专题报道在“两会”期间引发热议，有人大代表建议、政协委员提案直指我国工业软件体系与平台建设的重要性、紧迫性，以及重视的不足和现存的问题。


“两会”期间，由走向智能研究院等机构举办的题为“软件定义创新工业模式”的学术研讨会上，来自中国工程院、中科院、国务院发展研究中心、北大、北航、中国信息物理系统（CPS）发展论坛、中关村大数据产业联盟等研究机构30余位专家学者以及部分制造企业、IT企业代表就此话题开展深入研讨。


专家一致认为，国务院与工信部文件强调“软件定义”的重要作用，给工业转型创新发展带来新的视角、思路与机遇。如果说智能制造是中国工业必将跨入的大门，那么工业软件及其平台就是开门的金钥匙，应像重视工业互联网一样重视工业软件及其平台建设。




智能制造高度依赖“软件定义”


当前，“软件定义世界”SDX成为工业OT技术与信息IT技术融合的新趋势，工业设备的智能化水平越来越依赖工业技术软件化水平。国务院关于深化制造业与互联网融合发展的指导意见中要求：“强化软件支撑和定义制造业的基础性作用。”工信部《软件和信息技术服务业发展规划（2016~2020年）》中，将软件定义作为一种重要发展趋势，并将其视为“信息革命的新标志和新特征”。令人遗憾的是，目前人们对工业软件的重要性认识还不够，对工业软件平台的战略性也缺乏前瞻。工业软件的定义、分类、统计口径等基础研究都不足，还谈不上体系化、系统化、平台化发展。


走向智能研究院执行院长、中国信息物理系统发展论坛副秘书长、中国发明协会发明方法研究分会会长赵敏提出，软件是工业技术的替代器、黏结器、赋能器、映射器和创新器。工业装备的智能不断升级，主要是因为软件定义技术而实现的。各种工业现场、作业流程、装备产品中嵌入式、本地化或者云化的工业软件，构成了中国工业走向智能必不可少的知识平台，成为智能制造最为核心的“软零件、软部件、软装备”。


从软件定义的视角看智能制造，就是按照不同工业行业需求，搭建起一个或多个产学研协作定义的工业软件平台，进而在设计、工艺、流程、生产管理、运维管理、C2M、产品全生命周期管理等各个细分领域开展各行业的工业软件攻关，最终搭建智能化的软件协作开发与调度分发平台，将各类工业软件特别是App部署到各工业行业制造全流程、产品全生命周期以及产消互动的全场景，在更大范围、更广维度实现制造资源优化配置，并提供新型服务。


在各工业强国，工业软件无一例外皆出现于研制复杂产品的工业巨头或者大型工程项目之中。 中国信息物理系统（CPS）发展论坛专家咨询委员会委员、中航工业集团信息技术中心首席顾问宁振波介绍说，全球最大的工业软件公司——达索系统公司脱胎于达索飞机公司。德国工业4.0的旗手——西门子公司正是因为2006年并购UG，获得前麦道飞机公司开发的工业软件，从而吹响了工业4.0的号角。世界航空航天领域广泛使用的MSC力学分析软件，也是美国国家航空航天局（NASA）为实施“阿波罗”登月计划而研制的。可以说，没有经过复杂工业活动的淬炼，单靠研究人员在办公室和实验室里工作，是不可能打造出工业软件的“神兵利器”的。


宁振波等专家认为，作为全球制造大国，我们拥有世界上门类最齐全、产值最大的工业体系，但这个体系却是“跛脚”的，因为支撑各工业行业向智能制造转型至关重要的工业软件体系没有发育起来，这使得中国工业企业在迈向中国制造2025的道路上缺“芯”少“魂”。




中国本土工业软件潜力很大实力可用


中国工业企业关键设备利用率低下备受与会专家关注。数据表明，全球机床利用率日本高达80%，欧美差不多在70%左右，而中国平均只有30%左右。借助软件优化硬件运行效率存在巨大的服务空间。经过中国本土MES服务商与甲方企业的共同努力，目前海尔模具的机床利用率超过75%，中信戴卡提高到65%。事实证明，我国本土软件企业集中优势兵力，深耕细分行业，做好业务知识凝聚，在局部市场战胜国外软件是很有机会的。


今年2月23日，美国NOV公司（世界500强）休斯敦制造基地智能工厂成功验收。由北京施达优公司实施的这一项目获好评。该集团公司当即决定在其分布全球的20个制造工厂全面推广。这是中国的制造业运营管理系统软件首次进入发达国家市场。


华为企业业务集团 ICT规划与咨询部首席专家宋联昌认为，对新兴的工业互联网平台另一种理解就是工业软件平台。打造中国的工业软件平台最紧迫的是为企业凝聚行业优秀的、可用的知识和经验，支持中国企业的创新积累。不少著名企业，包括汽车合资企业已经应用了很多知名软件，但并未用到软件背后西方企业先进的开发流程、管理体系和最佳实践。当前华为与很多政府、企业共建智能制造云，或制造企业转型升级云，已经上线的软件云集聚了大量的实践和技术积累，可帮助制造企业快速、高起点、规范化地利用成熟的知识成果。


当前国外的工业互联网平台开始向中国企业渗透，不少国企也在拥抱这些平台，开展战略合作。对此，索为软件公司总裁李义章认为后果堪忧。一旦工业企业知识、技术完全依托外国平台，相当于四肢是自己的，神经系统却是别人的，产业安全面临极大挑战。发展本土平台不是为了重返闭关锁国的老路，而是面向开放的国际合作拥有筹码和话语权。


事实上，中国本土工业软件企业的规模、实力还很弱小，即使是本土龙头企业宝信软件，其2015年的营业收入也不到40亿元。随着高层对工业软件重要性认识的深化，政府政策红利、资本市场推动和本土制造业软件意识的觉醒，中国工业软件行业可望迎来爆发期。




工业软件平台与工业互联网平台异曲同工


北京航空航天大学机械工程及自动化学院博导、教授刘强认为，以前工业中的自动化靠硬件来实现，现在都是靠数字化、软件来实现。物理对象的数字化、虚拟化，只能依靠软件侧来实现，而不是实体侧。西门子公司推动发展的工业4.0，虽然未明确提及软件定义，但其数字工厂就是软件定义的工厂，核心是基于数据分享的合作平台TeamCenter，实质是PLM、MES、TIA三位一体的工厂解决方案。


索为软件李义章认为，过去的信息化技术主要解决工具替代的问题，如今工业软件要把工业的业务、技能转化为软件。专业软件成为企业最重要的资产，把软件装入提箱，可以随时重建一个工厂。美国国防部自适应运载车辆计划就是基于互联网构建的工业知识平台，把业务知识、技术封装成模块，变成协同、共用的知识资产，可以共享、流通和交易，从整体上促进整个制造业的发展。


软件定义的浪潮使得工业行业对细分的、专用的业务软件的需求呈现井喷态势。美国波音飞机787型飞机研制过程中用到8000多种软件，其中只有不到1000种是商业软件，其他7000多种是私有的工业软件。即使是工业巨头，也存在软件研发队伍跟不上需求发展的现实，这迫使全世界工业界加速跨界融合，通过同行分享、跨业协同等方法开展联合技术攻关。美国工业互联网联盟、德国工业4.0平台，从组织角度看，本质上就是新型工业软件的架构、技术、应用的研发与测试而组建的创新协作社区，从技术角度看，就是智能制造时代新型工业软件的平台或操作系统。


国务院发展研究中心信息中心研究员李广乾认为，全球工业强国的战略布局和实践已经表明，工业互联网平台、工业软件平台实质上具有高度的一致性，已经成为大国竞争的角力场、制高点。中国工业界不能永远在美、德等工业强国后面亦步亦趋。因此工业强基要有战略思维、战略远见。当前，平台化已经成为产业经济领域一大趋势，我国消费领域的电商平台成就显著，随着两化深度融合的加速，工业也会出现平台化现象，门槛更高、战略价值更高。应以举国之力打造国家级工业互联网平台、工业软件平台。
 
 
 
 
更多内容请关注：www.imefuture.com
 
 
来源：微信公众号 走向智能论坛 胡虎  查看全部

正如大多数现代软件开发人员通过实践所证明，容器技术确实能够为用户在物理及虚拟基础设施之上运行云原生应用程序提供更为理想的灵活性。容器技术能够将多层服务打包为一款应用程序，并确保其能够在不同计算环境之间往来移植，从而实现开发/测试，及生产性使用。
利用容器技术，用户能够更轻松地启动应用程序实例，快速满足峰值需求。另外，由于容器直接使用主机操作系统资源，体量较虚拟机更轻，这意味着容器能够高效发挥底层基础设施的固有优势。
说到这里，容器的前途似乎一片光明。然而必须承认，尽管容器运行时API非常适合管理单个容器，但一旦面对着分布在多台主机上且拥有数百套容器的大规模应用程序时，这些API就会变得力不从心。在这种情况下，容器需要接受管理并有序接入外部环境，从而实现调度、负载均衡以及分配等任务——Kubernetes正是能够实现上述目标的一款容器编排工具。
作为一套用于容器化应用程序部署、扩展与管理工作的开源系统，Kubernetes能够处理计算集群上的容器调度与工作负载管理，确保其严格按照用户的意愿运行。
Kubernetes由谷歌公司构建，融入了其在生产环境内运行容器时积累下的大量专业知识与经验。众所周知，谷歌公司拥有众多全球最为睿智且极具才华的软件开发人员，亦运行着规模最大的软件服务体系之一。这样的体系储备使得Kubernetes成为一套坚如磐石的平台，能够满足几乎一切组织机构的规模需求。
在今天的文章中，我们将具体探讨Kubernetes的重要意义及其将给DevOps团队带来的深远影响。
1面向当下的各类基础设施框架
时至今日，开发人员往往需要面向多套操作环境编写应用程序，具体包括本地专用服务器、虚拟化私有云以及AWS与Azure等公有云。
从传统角度讲，应用程序以及相关工具必须与其底层基础设施紧密契合。虽然这种作法确实具备一定潜在优势，但此类部署模型的实施成本亦相当昂贵。这意味着应用程序将在多个方面高度依赖于特定环境，包括与特定网络架构相关的性能特征、遵循云服务供应商提出的特定架构（例如专有编排技术）以及对特定后端存储系统的依赖性等等。
PaaS尝试解决这些问题，但随之而来的代价则往往包括在程序语言，以及应用程序框架等领域施以严格要求。因此，对于多数开发团队而言，PaaS通常并不适用。
Kubernetes通过为容器提供核心功能但又不施加强制性约束的方式解决了这种基础设施锁定难题。其通过将Kubernetes平台之内的多项功能加以结合实现这项目标，包括Pods与Services等。
2通过模块化提升管理效果
容器技术允许将各应用程序拆分成更小的部分，同时让各部分拥有更为明确的功能关注点。该抽象层提供的独立容器镜像允许我们从根本上重新考量如何构建分布式应用程序。
另外，这种模块化方法亦使得开发团队能够着眼于小处、更为专注地实现功能开发，这意味着各团队负责对应的特定容器即可。再有，其还允许用户对依赖关系加以隔离，同时对小型组件更为广泛地加以调优。
但这一切并不能单纯通过容器技术实现，还需要配合一套用于对这些模块化组件加以集成与编排的系统。Kubernetes利用Pods机制实现这一目标。
所谓Pods，代表着能够作为单一应用程序加以控制的一组容器集合。这些容器共享同样的资源集，包括文件系统、内核命名空间以及IP地址等。通过这种容器协作方式，Kubernetes能够有效避免将太多功能集中到单一容器镜像这样的错误实践中。
Kubernetes中的Services概念用于将具备类似功能的多个Pods整合为一组。Services可轻松进行配置以实现其可发现性、可观察性、横向扩展以及负载均衡。

3实现软件的规模化部署与更新
Devops是一种新兴方法，用于加快软件构建、测试与发布的整体过程。其结果是将软件团队的关注点由管理基础设施转向管理软件的规模化部署与更新工作。
大多数基础设施框架并不支持这一模式，但Kubernetes在这方面拥有出色的表现，特别是在KubernetesControllers的支持之下。归功于这些控制器，用户能够轻松利用基础设施管理整个应用程序生命周期。

部署控制器（Deployment Controller）能够简化多种复杂的管理任务，例如：

可扩展性。软件可以向外扩展跨越多个Pods实现初步部署，且相关部署可随时进行规模伸缩。

可见性。提供状态查询功能以判断部署工人和的完成情况、当前执行状态以及失败问题。

节约时间。用户可随时暂停部署并在稍后加以恢复。

版本控制。利用新的应用程序镜像版本对已部署Pods进行更新，并在发现当前版本存在不稳定问题时回滚至早期部署版本。
另外，Kubernetes还能够显著简化多种特定部署操作，这一点对于现代应用程序开发者而言极具现实意义。其中具体包括：
自动横向扩展。Kubernetes autoscalers能够自动根据特定资源的使用量对Pods的部署数量进行调整（在已定义的限制范围内）。

滚动更新。Kubernetes采取“滚动方式”实现编排，且可跨越部署范围内的全部Pods。这些滚更新可进行编排，并以预定义方式配合当前可能尚不可用的Pods数量以及暂时存在的闲置Pods数量。

金丝雀部署。作为一项实用性模式，我们在部署新版本之前，通常需要以实验性方式在生产环境中进行试部署，同时保证新旧版本并行运作。在确定一切正常后，逐步提升新部署规模并同步降低原有部署版本规模。

与存在强烈专用属性的传统方案不同，Kubernetes能够为广泛的应用类型提供支持。它不会限定应用程序框架（例如Wildfly）、指定受支持语言运行时（Java、Python与Ruby等）、仅适用于12因素应用程序或者区分“应用程序”与“服务”。相反，Kubernetes支持极为广泛的工作负载类型，其中包括无状态、有状态以及数据处理型工作负载。如果应用程序能够在容器内运行，其即可在Kubernetes上正常起效。

4为云原生应用奠定基础
鉴于当前容器技术获得的高度关注，越来越多管理与编排工具开始陆续出现。目前流行的方案包括Apache Mesos with Marathon、Docker Swarm、AWS EC2 Container Service（简称ECS）以及HasiCorp的Nomad。

当然各类方案皆拥有自己的特色与优势。Docker Swarm能够与Docker运行时紧密对接，帮助用户更轻松地由Docker过渡至Swarm；Mesos with Marathon不仅限于容器范畴，亦可部署各种类型的其它应用程序；AWS ECS可供AWS用户轻松访问。
然而，Kubernetes集群能够运行在EC2之上，并与AWS旗下的各类服务实现对接，具体包括Amazon弹性块存储（Elastic Block Storage）、弹性负载均衡（Elastic LoadBalancing）、自动规模伸缩组（Auto Scaling Groups）等。

这些框架在功能与特性方面存在大量交集，不过凭借着自身架构、创新成果以及庞大的开源技术社区等优势，Kubernetes仍然保持着极高人气。

Kubernetes的出现标志着DevOps的发展迎来突破，因为其允许开发者充分满足现代软件的开发要求。在缺少Kubernetes的情况下，开发团队常常被迫自行编写软件部署、扩展及更新工作流。部分企业甚至会建立大型团队单独处理此类任务。Kubernetes能够帮助我们充分发挥容器技术的既有优势，同时构建起能够在任意环境下运行的云原生应用程序，而不再需要受缚于云特定要求。
总结而言，Kubernetes代表着我们长久以来一直期待的高效应用程序开发与操作模式。 查看全部

论文发表在1999年的操作系统设计与实现国际会议上（OSDI99）。没错，这个Loskov就是提出著名的里氏替换原则（LSP）的人，2008年图灵奖得主。
OSDI99这篇论文描述了一种副本复制（replication）算法解决拜占庭容错问题。作者认为拜占庭容错算法将会变得更加重要，因为恶意攻击和软件错误的发生将会越来越多，并且导致失效的节点产生任意行为。（拜占庭节点的任意行为有可能误导其他副本节点产生更大的危害，而不仅仅是宕机失去响应。）而早期的拜占庭容错算法或者基于同步系统的假设，或者由于性能太低而不能在实际系统中运作。这篇论文中描述的算法是实用的，因为该算法可以工作在异步环境中，并且通过优化在早期算法的基础上把响应性能提升了一个数量级以上。作者使用这个算法实现了拜占庭容错的网络文件系统（NFS），性能测试证明了该系统仅比无副本复制的标准NFS慢了3%。
1概要介绍
论文提出解决拜占庭容错的状态机副本复制（state machine replication）算法。这个算法在保证活性和安全性（liveness & safety）的前提下提供了(n-1)/3的容错性。从Lamport教授在1982年提出拜占庭问题开始，已经有一大堆算法去解决拜占庭容错了。但是一句话概括：这些算法都是狗屎！PBFT算法跟这些妖艳贱货完全不同，在只读操作中只使用1次消息往返（message round trip），在只写操作中只使用2次消息往返，并且在正常操作中使用了消息验证编码（Message Authentication Code,简称MAC），而造成妖艳贱货性能低下的公钥加密（public-key cryptography）只在发生失效的情况下使用。作者不仅提出算法，而且使用这个算法实现了一个牛逼的系统（拜占庭容错的NFS），具体特性如下：
首次提出在异步网络环境下使用状态机副本复制协议

使用多种优化使性能显著提升

实现了一种拜占庭容错的分布式文件系统

为副本复制的性能损耗提供试验数据支持

2系统模型
系统假设为异步分布式的，通过网络传输的消息可能丢失、延迟、重复或者乱序。假设节点的失效必须是独立发生的，也就是说代码、操作系统和管理员密码这些东西在各个节点上是不一样的。（那么如果节点失效不独立发生，PBFT算法就失效了吗？）
使用了加密技术来防止欺骗攻击和重播攻击，以及检测被破坏的消息。消息包含了公钥签名（其实就是RSA算法）、消息验证编码（MAC）和无碰撞哈希函数生成的消息摘要（message digest）。使用m表示消息，mi表示由节点i签名的消息，D(m)表示消息m的摘要。按照惯例，只对消息的摘要签名，并且附在消息文本的后面。并且假设所有的节点都知道其他节点的公钥以进行签名验证。
3
服务属性

论文算法实现的是一个具有确定性的副本复制服务，这个服务包括了一个状态（state）和多个操作（operations）。这些操作不仅能够进行简单读写，而且能够基于状态和操作参数进行任意确定性的计算。客户端向副本复制服务发起请求来执行操作，并且阻塞以等待回复。副本复制服务由n个节点组成。
算法在失效节点数量不超过（n-1)/3的情况下同时保证安全性和活性（safety & liveness）。安全性是指副本复制服务满足线性一致性（linearizability）,就像中心化系统一样原子化执行操作。安全性要求失效副本的数量不超过上限，但是对客户端失效的数量和是否与副本串谋不做限制。系统通过访问控制来限制失效客户端可能造成的破坏，审核客户端并阻止客户端发起无权执行的操作。同时，服务可以提供操作来改变一个客户端的访问权限。因为算法保证了权限撤销操作可以被所有客户端观察到，这种方法可以提供强大的机制从失效的客户端攻击中恢复。
算法不依赖同步提供安全性，因此必须依靠同步提供活性。否则，这个算法就可以被用来在异步系统中实现共识，而这是不可能的（由Fischer1985的论文证明）。算法保证活性，即所有客户端最终都会收到针对他们请求的回复，只要失效副本的数量不超过（n-1)/3，并且延迟delay(t)不会无限增长。这个delay(t)表示t时刻发出的消息到它被目标最终接收的时间间隔，假设发送者持续重传直到消息被接收。这时一个相当弱的同步假设，因为在真实系统中网络失效最终都会被修复。但是这就规避了Fischer1985提出的异步系统无法达成共识的问题。
算法弹性是达到最优的：当存在f个失效节点时必须保证存在至少3f+1 个副本数量，这样才能保证在异步系统中提供安全性和活性。这么多数量的副本是需要的，因为在同n-f个节点通讯后系统必须做出正确判断，由于f个副本有可能失效而不发回响应。但是，有可能f个没有失效的副本不发回响应（是因为网络延迟吗？），因此f个发回响应的副本有可能是失效的。尽管如此，系统仍旧需要足够数量非失效节点的响应，并且这些非失效节点的响应数量必须超过失效节点的响应数量，即n-2f>f，因此得到n>3f。
算法不能解决信息保密的问题，失效的副本有可能将信息泄露给攻击者。在一般情况下不可能提供信息保密，因为服务操作需要使用参数和服务状态处理任意的计算，所有的副本都需要这些信息来有效执行操作。当然，还是有可能在存在恶意副本的情况下通过秘密分享模式（secret sharing scheme）来实现私密性，因为参数和部分状态对服务操作来说是不可见的。


4
算法详解
PBFT是一种状态机副本复制算法，即服务作为状态机进行建模，状态机在分布式系统的不同节点进行副本复制。每个状态机的副本都保存了服务的状态，同时也实现了服务的操作。将所有的副本组成的集合使用大写字母R表示，使用0到|R|-1的整数表示每一个副本。为了描述方便，假设|R|=3f+1，这里f是有可能失效的副本的最大个数。尽管可以存在多于3f+1个副本，但是额外的副本除了降低性能之外不能提高可靠性。
PBFT主要包含三个部分，首先介绍视图（view）、演员（replica）和角色（primary、backups）
所有的副本在一个被称为视图（View）的轮换过程（succession of configuration）中运作。在某个视图中，一个副本作为主节点（primary），其他的副本作为备份（backups）。视图是连续编号的整数。主节点由公式p = v mod |R|计算得到，这里v是视图编号，p是副本编号，|R|是副本集合的个数。当主节点失效的时候就需要启动视图更换（view change）过程。Viewstamped Replication算法和Paxos算法就是使用类似方法解决良性容错的。
主要特点如下：
客户端向主节点发送请求调用服务操作

主节点通过广播将请求发送给其他副本

所有副本都执行请求并将结果发回客户端
客户端需要等待f+1个不同副本节点发回相同的结果，作为整个操作的最终结果。
同所有的状态机副本复制技术一样，PBFT对每个副本节点提出了两个限定条件：
1、所有节点必须是确定性的。也就是说，在给定状态和参数相同的情况下，操作执行的结果必须相同；
2、所有节点必须从相同的状态开始执行。
在这两个限定条件下，即使失效的副本节点存在，PBFT算法对所有非失效副本节点的请求执行总顺序达成一致，从而保证安全性。
接下去描述简化版本的PBFT算法，忽略磁盘空间不足和消息重传等细节内容。并且，本文假设消息验证过程是通过数字签名方法实现的，而不是更加高效的基于消息验证编码（MAC）的方法。
客户端
客户端c向主节点发送<REQUEST,o,t,c>请求执行状态机操作o，这里时间戳t用来保证客户端请求只会执行一次。客户端c发出请求的时间戳是全序排列的，后续发出的请求比早先发出的请求拥有更高的时间戳。例如，请求发起时的本地时钟值可以作为时间戳。
每个由副本节点发给客户端的消息都包含了当前的视图编号，使得客户端能够跟踪视图编号，从而进一步推算出当前主节点的编号。客户端通过点对点消息向它自己认为的主节点发送请求，然后主节点自动将该请求向所有备份节点进行广播。
副本发给客户端的响应为<REPLY,v,t,c,i,r>，v是视图编号，t是时间戳，i是副本的编号，r是请求执行的结果。

客户端等待f+1个从不同副本得到的同样响应，同样响应需要保证签名正确，并且具有同样的时间戳t和执行结果r。这样客户端才能把r作为正确的执行结果，因为失效的副本节点不超过f个，所以f+1个副本的一致响应必定能够保证结果是正确有效的。
如果客户端没有在有限时间内收到回复，请求将向所有副本节点进行广播。如果请求已经在副本节点处理过了，副本就向客户端重发一遍执行结果。如果请求没有在副本节点处理过，该副本节点将把请求转发给主节点。如果主节点没有将该请求进行广播，那么就有认为主节点失效，如果有足够多的副本节点认为主节点失效，则会触发一次视图变更。
5PBFT算法主线流程
每个副本节点的状态都包含了服务的整体状态，副本节点上的消息日志(message log)包含了该副本节点接受(accepted)的消息，并且使用一个整数表示副本节点的当前视图编号。
当主节点p收到客户端的请求m，主节点将该请求向所有副本节点进行广播，由此一场轰轰烈烈的三阶段协议（three-phase protocol）拉开了序幕。在这里，至于什么消息过多需要缓存的情况我们就不管了，这不是重点。
我们重点讨论预准备（pre-prepare）、准备(prepare)和确认(commit)这三个历史性阶段。预准备和准备两个阶段用来确保同一个视图中请求发送的时序性（即使对请求进行排序的主节点失效了），准备和确认两个阶段用来确保在不同的视图之间的确认请求是严格排序的。
在预准备阶段，主节点分配一个序列号n给收到的请求，然后向所有备份节点群发预准备消息，预准备消息的格式为<<PRE-PREPARE,v,n,d>,m>，这里v是视图编号，m是客户端发送的请求消息，d是请求消息m的摘要。
请求本身是不包含在预准备的消息里面的，这样就能使预准备消息足够小，因为预准备消息的目的是作为一种证明，确定该请求是在视图v中被赋予了序号n，从而在视图变更的过程中可以追索。另外一个层面，将“请求排序协议”和“请求传输协议”进行解耦，有利于对消息传输的效率进行深度优化。
只有满足以下条件，各个备份节点才会接受一个预准备消息：
请求和预准备消息的签名正确，并且d与m的摘要一致。
该备份节点从未在视图v中接受过序号为n但是摘要d不同的消息m。
预准备消息的序号n必须在水线（watermark）上下限h和H之间。
水线存在的意义在于防止一个失效节点使用一个很大的序号消耗序号空间。

如果备份节点i接受了预准备消息<<PRE-PREPARE,v,n,d>,m>，则进入准备阶段。在准备阶段的同时，该节点向所有副本节点发送准备消息<PREPARE,v,n,d,i>，并且将预准备消息和准备消息写入自己的消息日志。如果看预准备消息不顺眼，就什么都不做。
包括主节点在内的所有副本节点在收到准备消息之后，对消息的签名是否正确，视图编号是否一致，以及消息序号是否满足水线限制这三个条件进行验证，如果验证通过则把这个准备消息写入消息日志中。
我们定义准备阶段完成的标志为副本节点i将(m,v,n,i)记入其消息日志，其中m是请求内容，预准备消息m在视图v中的编号n，以及2f个从不同副本节点收到的与预准备消息一致的准备消息。每个副本节点验证预准备和准备消息的一致性主要检查：视图编号v、消息序号n和摘要d。
预准备阶段和准备阶段确保所有正常节点对同一个视图中的请求序号达成一致。接下去是对这个结论的形式化证明：如果prepared(m,v,n,i)为真，则prepared(m’,v,n,j)必不成立，这就意味着至少f+1个正常节点在视图v的预准备或者准备阶段发送了序号为n的消息m。
当(m,v,n,i)条件为真的时候，副本i将<COMMIT,v,n,D(m),i>向其他副本节点广播，于是就进入了确认阶段。每个副本接受确认消息的条件是：1）签名正确；2）消息的视图编号与节点的当前视图编号一致；3）消息的序号n满足水线条件，在h和H之间。一旦确认消息的接受条件满足了，则该副本节点将确认消息写入消息日志中。（补充：需要将针对某个请求的所有接受的消息写入日志，这个日志可以是在内存中的）。
我们定义确认完成committed(m,v,n)为真得条件为：任意f+1个正常副本节点集合中的所有副本i其prepared(m,v,n,i)为真；本地确认完成committed-local(m,v,n,i)为真的条件为：prepared(m,v,n,i)为真，并且i已经接受了2f+1个确认（包括自身在内）与预准备消息一致。确认与预准备消息一致的条件是具有相同的视图编号、消息序号和消息摘要。
确认阶段保证了以下这个不变式（invariant）：对某个正常节点i来说，如果committed-local(m,v,n,i)为真则committed(m,v,n)也为真。这个不变式和视图变更协议保证了所有正常节点对本地确认的请求的序号达成一致，即使这些请求在每个节点的确认处于不同的视图。更进一步地讲，这个不变式保证了任何正常节点的本地确认最终会确认f+1个更多的正常副本。

每个副本节点i在committed-local(m,v,n,i)为真之后执行m的请求，并且i的状态反映了所有编号小于n的请求依次顺序执行。这就确保了所有正常节点以同样的顺序执行所有请求，这样就保证了算法的正确性（safety）。在完成请求的操作之后，每个副本节点都向客户端发送回复。副本节点会把时间戳比已回复时间戳更小的请求丢弃，以保证请求只会被执行一次。

我们不依赖于消息的顺序传递，因此某个副本节点可能乱序确认请求。因为每个副本节点在请求执行之前已经将预准备、准备和确认这三个消息记录到了日志中，这样乱序就不成问题了。

下图展示了在没有发生主节点失效的情况下算法的正常执行流程，其中副本0是主节点，副本3是失效节点，而C是客户端。





6垃圾回收
为了节省内存，系统需要一种将日志中的无异议消息记录删除的机制。为了保证系统的安全性，副本节点在删除自己的消息日志前，需要确保至少f+1个正常副本节点执行了消息对应的请求，并且可以在视图变更时向其他副本节点证明。另外，如果一些副本节点错过部分消息，但是这些消息已经被所有正常副本节点删除了，这就需要通过传输部分或者全部服务状态实现该副本节点的同步。因此，副本节点同样需要证明状态的正确性。
在每一个操作执行后都生成这样的证明是非常消耗资源的。因此，证明过程只有在请求序号可以被某个常数（比如100）整除的时候才会周期性地进行。我们将这些请求执行后得到的状态称作检查点（checkpoint），并且将具有证明的检查点称作稳定检查点（stable checkpoint）。
副本节点保存了服务状态的多个逻辑拷贝，包括最新的稳定检查点，零个或者多个非稳定的检查点，以及一个当前状态。写时复制技术可以被用来减少存储额外状态拷贝的空间开销。
检查点的正确性证明的生成过程如下：当副本节点i生成一个检查点后，向其他副本节点广播检查点消息<CHECKPOINT,n,d,i>，这里n是最近一个影响状态的请求序号，d是状态的摘要。每个副本节点都默默地在各自的日志中收集并记录其他节点发过来的检查点消息，直到收到来自2f+1个不同副本节点的具有相同序号n和摘要d的检查点消息。这2f+1 个消息就是这个检查点的正确性证明。

具有证明的检查点成为稳定检查点，然后副本节点就可以将所有序号小于等于n的预准备、准备和确认消息从日志中删除。同时也可以将之前的检查点和检查点消息一并删除。
检查点协议可以用来更新水线（watermark）的高低值（h和H），这两个高低值限定了可以被接受的消息。水线的低值h与最近稳定检查点的序列号相同，而水线的高值H=h+k，k需要足够大才能使副本不至于为了等待稳定检查点而停顿。加入检查点每100个请求产生一次，k的取值可以是200。
视图变更

视图变更协议在主节点失效的时候仍然保证系统的活性。视图变更可以由超时触发，以防止备份节点无期限地等待请求的执行。备份节点等待一个请求，就是该节点接收到一个有效请求，但是还没有执行它。当备份节点接收到一个请求但是计时器还未运行，那么它就启动计时器；当它不再等待请求的执行就把计时器停止，但是当它等待其他请求执行的时候再次情动计时器。 查看全部

一.在工业互联网信息时代里，硬件与软件之间皆需要实现互联互通，消除信息孤岛，如何去实现工业软件与硬件之间的无缝接轨？
 
 
当前工业软件的开放性以及与硬件接轨的技术有哪些进展？
 
 
研华（中国）公司工业自动化事业群物联网核心软件WebAccess产品经理  韦伟：
 
 
 
从工业软件的开放性来说，未来应该越来越趋向于标准化，但是要分几个层面，例如底层控制层，过去的总线协议五花八门，现在EtherCAT逐步会成为底层控制的通用与标准协议；

在工厂级设备互联部分，OPC UA的标准逐步得到客户的认可，现在无论软件还是硬件都集成了标准的OPC UA的接口。

与云端对接的部分，现在轻量化的互联网MQTT的协议也逐渐成为各家云平台/硬件设备的标准协议。
  
 
 
深圳市智物联网络有限公司市场总监  唐力：
 
 
工业物联网信息化的第一步就是打通工业设备和软件之间的信息壁垒，针对这个问题，智物联研发推出的硬件设备（数据采集设备）支持RS232、RS485串口，CAN、MODBUS、PPI等常见或私有协议，可以从用户设备的控制器或者PLC中取得数据，再将这些数据整理、处理、传输到我们的应用软件中，进行精准地分析与控制。
 
 
 
亚控科技营销总监，郑炳权：
 
 
首先从设备层来看，从原则上来说，只要硬件的数据接口方面是开放的，能够提供通讯协议，那么相应的信息管理软件都能够实现设备层数据的连接。例如现在很多设备大体上都采用标准的控制系统或者控制器，那么这些设备中有很多是采用各类现场总线协议，例如Profibus，CCLink，controlNET等等，这些设备都能够实现连接；其次，从信息软件层面看，有些信息软件可以接收OPC协议的数据，也基本具备数据连接的基础。再则，目前大部分的信息软件的数据平台都是采用关系数据库，所以如果从设备层采集到的数据转存能够转存到关系数据库，也能够实现设备层和信息管理层数据的互联。总的来说，随着智能制造的需要，设备制造商和终端用户对于数据接口的开放性越来越关注，实现互联的比例越来越高。
 
 
 
苏州美名有限公司技术总监  张皆乐：
 
 
近十年以来，随着民用互联网、物联网软件技术的飞速发展，工业软件也借助这股技术发展的浪潮，逐步采用新出现的软件技术来解决工业行业内的各种需求和问题。由于工业行业自身的特点，以及工业数据的高价值、高保密性，工业软件的开放程度仍然较低。比如，相比于民用行业的软件系统纷纷向各种云计算平台迁移，工业界使用云计算的意愿度依然较低，各企业对于云计算平台的实时性、安全性、可靠性有着不少担心，对于把自己的系统和数据开放出去也很排斥。数据的孤岛效应还很突出。美名软件所接触的广大工业行业客户的决策过程，也验证了这个现状。但是另一方面，这个现状有悖于当前广大用户和国家对于各系统横向和纵向的互联互通、推动工业物联网和智能制造的要求，所以工业企业也逐步意识到系统开放的好处和必要性。在这个博弈的过程中，我相信系统和数据的开放最终是大势所趋，首先拥抱开放性的企业也会成为最大的赢家。而工业领域的各种开放性标准和技术，也将推动整个行业向这个方向发展。
 
 
与硬件接轨的软件技术则是一个更技术层面的话题。最常见的就是工业软件直接通过各种标准化的现场总线（Fieldbus）协议与各个硬件设备进行通讯。目前市场上有近百种现场总线协议，它们有着各自鲜明的特点（安全性、实时性、带宽和性能等），服务于各种不同的工业应用场景。但是，随着工业现场自动化程度越来越高，在多总线、多设备供应商的复杂场景中，需要一种更加统一和开放的软件标准来访问各种现场硬件设备。目前市场上最匹配、最成熟的技术是2000年推出的FDT技术（Field Device Technology）。它实现了跨总线、覆盖各个供应商设备的互联互通。用户可以通过FDT技术实现整个工业现场设备信息的透明访问。目前全球工业自动化行业的大部分领先企业都已经成为了FDT的会员，并且推动该项技术的继续发展。
 
 
另外，随着工业物联网的热潮的到来，将工业现场的设备连接到各种云平台的需求也越来越多。各种相应的解决方案也逐渐出现:既可以利用传统的互联网技术，比如HTTPS协议；也可以采用新的针对物联网的协议规范，如MQTT。这些技术的实现可以内嵌到工业现场已有的控制器或者网关中，或者额外添加物联网专有的网关设备来连接工业现场和云平台。
 
 
因此，现在与硬件接轨的软件技术的发展重心就集中于上述两方面：1.以FDT为代表的处于工业现场的统一的互联互通技术；2.以物联网网关硬件为代表的连接至云平台的物联网技术。当然，后者也必须依赖于前者，因为现场层面的互联互通是前提条件。
 
 
 
易网技术有限公司市场总监   刘刚：
 
 
当前情况下，工业软件的开放性与硬件接轨的技术是所有制造企业与像我们这类智能制造解决方案提供商共同关注的焦点，遗憾的是现实情况不容乐观，技术实力比较强劲的部分企业正式凭借其竖立起的技术壁垒，成就了极大的竞争优势。但是尺有所长寸有所短，不同解决方案提供商针对不同行业、不同领域、不同需求甚至根据自身资源分配和技术实力的差别，有着不同优势，特别是在中国制造业这个发展极其不均匀有着显著特点的领域，所谓最“先进”的并非就一定是最合适的。当落地到具体的项目中时，我们经常遇到这样的问题：客户对硬件的要求较高，但对软件的需求则相对简单，此时如果应用与硬件相匹配的软件则会超出预算，而此时如果该硬件厂商不开放通信协议那就会陷入僵局，产生所谓的信息孤岛。目前业内比较常见的做法是通过协议转换来达到软件开放和硬件接轨的问题，只要他们开放了接口我们才能读取生产过程中产生的数据，从而进行有效的分析，发现问题所在，最后对生产进行有效的纠错和指导。当前政府相关部门也已经发现了这个问题，正在着手进行规范和调整，CPS标准的制定就是一个尝试，易往信息也参与了该项标准的制定，我们的解决方案与CPS的理念不谋而合，通过信息、数据与自动化设备的交互，MES生产管理系统连接上层ERP和下层自动化设备，解决计划信息与设备执行中间的断层问题；用APS系统提供的强劲算法科学计算制造周期和排程，制定最佳生产计划；所有信息都在一体化平台搭建的网络中流通和传递，消除信息孤岛，提高效率。易往信息的产品实现设备与设备的对话，让管理者在更高的层面总领全局，从而打造透明工厂、实现智慧制造。标准制定能够总结、归纳智能制造与CPS的关系以及研究的方法论；规划CPS应用领域及未来愿景；讨论CPS的需求和重点实现的功能；完成CPS的参考模型及通用技术要求，达到规范、指引行业发展的作用。
 
 
 
[size=15]工业软件与硬件设备进行无缝接轨的过程中，遇到哪些挑战问题？[/size]
 
 
亚控科技营销总监    郑炳群：
 
 
尽管现在已经有相对标准的手段可以实现数据的互联，但是在很多方面是都存在问题：
 
一是通讯协议种类太多，导致信息软件实施商连接软件非常困难，工程量大，设备互联的造价成本高；
 
二是由于采用中转文件或者中转数据库的方式实现数据互联，系统的实时性比较差；
 
三是很多设备虽然开放了通讯接口，但是开放的数据有限，导致需要的数据采集不到，不利于生产管理和分析；
 
四是设备分散，需要敷设物理连接的采集网络，提高实施费用也减低了采集数据的可靠性；
 
五是生产数据量庞大，往往很多信息软件系统处理不过来，导致需要丢失大量的过程数据，生产数据的时间精度低，不利于后续业务应用的追溯需要。
 
 
 
深圳市智物联网络有限公司市场总监   唐力：
 
 
硬件与设备之间除了物理对接之外，需要有对应的数据通讯协议，常见的或工业中标准的协议都很好实现，但是还会遇到一些协议不对外开放的设备企业，这时候我们就不能通过硬件直接从控制器中取得数据，需要采用其他的解决方案来实现数据的采集。
 
 
 
苏州美名软件有限公司技术总监    张皆乐：
 
 
最大的挑战是，不少厂商出于保护商业秘密的目的，拒绝或者尽可能少的对外提供硬件设备的参数、状态信息。即使采用了开放的技术，实现了相关的标准接口，但是用户和系统厂家仍然无法有效地获得所需的数据。这个已经成为阻碍信息化、互联互通的一大障碍。这个问题也存在于FDT技术的应用中。FDT第一个版本中，某些数据访问的接口被定义为厂商可选的，导致的直接结果是，绝大部分厂商没有去实现这些接口，使得用户和系统厂商无法获得相关数据。即使某些厂商实现了这些标准接口，所提供的设备数据也非常有限，比如仅提供20%的设备信息，等等。当然FDT组织也意识到了这个问题，因此在制定FDT规范第二个版本的时候，通过两个方面来解决这个问题：1.相关的数据接口被定义为强制要求；2.在FDT的认证测试中验证所提供的设备信息必须满足用户和系统所需要的最小集合。这样就能够从标准的角度，来推动厂商提供相应的数据（注：FDT2是2012年4月正式发布的。）。
 
同时在发展中也存在其它的一些挑战，诸如，国内厂商重硬轻软；对于国际上最新的技术动态不关心、不了解；软硬件产品的功能简单和稳定性低等等，则需要时间来转变观念，逐步提高。
 
 
 
[size=15]贵单位有什么可靠的解决方案与我们分享？[/size]
 
 
亚控科技营销总监，郑炳权：
 
 
实现和生产设备层通讯是生产管理信息软件发挥作用的关键环节，也只有和生产设备层实现实时的信息通讯，我们构建的信息管理系统才不至于彷如空中楼阁，才能够有效的指导生产，分析生产存在的问题，为实现智能制造打下坚实的基础。亚控科技过去的业务主要聚焦在生产监控层，在过去21年的积累过程中，亚控科技的数据通讯软件KingIOServer已经开发了大量生产设备的接口。据不完全统计，可以支持的各类PLC、仪表、控制器、变频器、数据采集模块和数据板卡等设备已多达6000多种的通讯协议，同时，KingIOServer还提供了便易的SDK开发包，可以用来开发市面上不流行的设备接口通讯，满足各行业客户的特定需要。除此之外，经过KingIOServer采集的数据可以直接存入亚控科技刚推出的管控一体化全组态平台KingFusion3.0的时空数据库中，该时空数据库在单服务器的情况下可以储存少于100万个过程数据采集点的连续数据，非常高效。
 
另外一方面，我们经常会发现当我们需要一些数据的时候，我们信息系统中却没有，这往往是系统规划时考虑不周导致的。我们建议用户应基于业务需求，从应用的纵向角度来考虑，根据需要进行采集数据。对于一个信息管理系统，总体上来说应该有6个方面的过程数据：生产计划和生产进度数据、设备运行数据、物料库存和消耗数据、工艺质量数据、能源计划和消耗数据、人员岗位和操作数据。建议可以依据生产管理系统的人、物、料、法、环方面来考虑并采集数据，实现数据的完整性、准确型和实时性的采集。
 
 
 
 
研华（中国）公司工业自动化事业群物联网核心软件WebAccess产品经理  韦伟：
 
 
研华在设备自动化层面这几年也有非常多的投入，有独立的业务单位在经营，可以说是研华在走向行业发展路途中非常成功的一步，我们在运动控制、机器视觉、机械人都有完善的产品，在这些底层控制系统中研华也加入EtherCAT技术协会成为会员单位，在研华的控制系统中，将此协议作为我们多种设备的的标准协议；
 
在面向智能制造的应用实践中，我们诸多产品也集成了标准的OPC UA的协议，例如研华PAC控制器、触摸屏、软件平台，为了整合大平台化的经营模式，未来该协议会作为我们对外一种标准接口；
 
目前研华在和多家国内外厂家进行云端的合作。MQTT作为云端对接标准协议，研华在底层智能终端上也整合了不同厂家的MQTT协议，底层智能终端可以将工业现场的设备/产线的数据采集上来，并可以通过标准的MQTT对接到云平台，实现一个海量数据的上传，同时研华软件平台同时可以通过MQTT订阅的方式从云平台读取数据，并以BI的方式进行呈现。
 
 
 
苏州美名软件有限公司技术总监  张皆乐：
 
 
研华在设备自动化层面这几年也有非常多的投入，有独立的业务单位在经营，可以说是研华在走向行业发展路途中非常成功的一步，我们在运动控制、机器视觉、机械人都有完善的产品，在这些底层控制系统中研华也加入EtherCAT技术协会成为会员单位，在研华的控制系统中，将此协议作为我们多种设备的的标准协议；
 
在面向智能制造的应用实践中，我们诸多产品也集成了标准的OPC UA的协议，例如研华PAC控制器、触摸屏、软件平台，为了整合大平台化的经营模式，未来该协议会作为我们对外一种标准接口；
 
目前研华在和多家国内外厂家进行云端的合作。MQTT作为云端对接标准协议，研华在底层智能终端上也整合了不同厂家的MQTT协议，底层智能终端可以将工业现场的设备/产线的数据采集上来，并可以通过标准的MQTT对接到云平台，实现一个海量数据的上传，同时研华软件平台同时可以通过MQTT订阅的方式从云平台读取数据，并以BI的方式进行呈现。
 
 来源：《智慧工厂》杂志 科技自动化联盟
 
 
 
 
 
 
更多内容请关注：www.imefuture.com
 
七个值得研究的颠覆性创新领域
中国科技自动化联盟王健：关于工业软件的一点随想
从技术角度，回顾2016年语音识别的发展
智造家 查看全部

从以下几个方面来看
1，代码稳定，没有隐患。
2，执行效率高。
3，可读性高。
4，便于移植。
下面发一些我在网上看到的技巧和自己的一些经验来和大家分享;
1 1 、如果可以的话少用库函数，便于不同的 u mcu  和编译器间的移植
2 2 、选择合适的算法和数据结构
应该熟悉算法语言，知道各种算法的优缺点，具体资料请参见相应的参考资
料，有很多计算机书籍上都有介绍。将比较慢的顺序查找法用较快的二分查找或
乱序查找法代替，插入排序或冒泡排序法用快速排序、合并排序或根排序代替，
都可以大大提高程序执行的效率。.选择一种合适的数据结构也很重要，比如你
在一堆随机存放的数中使用了大量的插入和删除指令，那使用链表要快得多。数
组与指针语句具有十分密码的关系，一般来说，指针比较灵活简洁，而数组则比
较直观，容易理解。对于大部分的编译器，使用指针比使用数组生成的代码更短，
执行效率更高。但是在 Keil 中则相反，使用数组比使用的指针生成的代码更短。
3 3 、使用尽量小的数据类型
能够使用字符型(char)定义的变量，就不要使用整型(int)变量来定义;能够
使用整型变量定义的变量就不要用长整型(long int)，能不使用浮点型(float)
变量就不要使用浮点型变量。当然，在定义变量后不要超过变量的作用范围，如
果超过变量的范围赋值，C 编译器并不报错，但程序运行结果却错了，而且这样
的错误很难发现。在 ICCAVR 中，可以在 Options 中设定使用 printf 参数，尽量
使用基本型参数(%c、%d、%x、%X、%u 和%s 格式说明符)，少用长整型参数
(%ld、%lu、%lx 和%lX 格式说明符)，至于浮点型的参数(%f)则尽量不要使用，
其它 C 编译器也一样。在其它条件不变的情况下，使用%f 参数，会使生成的代
码的数量增加很多，执行速度降低。
4 4 、使用自加、自减指令
通常使用自加、自减指令和复合赋值表达式(如 a-=1 及 a+=1 等)都能够生成
高质量的程序代码，编译器通常都能够生成 inc 和 dec 之类的指令，而使用 a=a+1
或 a=a-1 之类的指令，有很多 C 编译器都会生成二到三个字节的指令。在 AVR
Ofweek 电子工程网
单片适用的 ICCAVR、GCCAVR、IAR 等 C 编译器以上几种书写方式生成的代码是一
样的，也能够生成高质量的 inc 和 dec 之类的的代码。
5 5 、减少运算的强度
可以使用运算量小但功能相同的表达式替换原来复杂的的表达式。如下：
(1)、求余运算。
a=a%8;
可以改为：
a=a&7;
说明：位操作只需一个指令周期即可完成，而大部分的 C 编译器的“%”运
算均是调用子程序来完成，代码长、执行速度慢。通常，只要求是求 2n 方的余
数，均可使用位操作的方法来代替。
(2)、平方运算
a=pow(a,2.0);
可以改为：
a=a*a;
说明：在有内置硬件乘法器的单片机中(如 51 系列)，乘法运算比求平方运
算快得多，因为浮点数的求平方是通过调用子程序来实现的，在自带硬件乘法器
的 AVR 单片机中，如 ATMega163 中，乘法运算只需 2 个时钟周期就可以完成。既
使是在没有内置硬件乘法器的 AVR 单片机中，乘法运算的子程序比平方运算的子
程序代码短，执行速度快。
如果是求 3 次方，如：
a=pow(a,3.0);
更改为：
a=a*a*a;
则效率的改善更明显。
(3)、用移位实现乘除法运算
a=a*4;
Ofweek 电子工程网
b=b/4;
可以改为：
a=a<<2;
b=b>>2;
说明：通常如果需要乘以或除以 2n，都可以用移位的方法代替。在 ICCAVR
中，如果乘以 2n，都可以生成左移的代码，而乘以其它的整数或除以任何数，
均调用乘除法子程序。用移位的方法得到代码比调用乘除法子程序生成的代码效
率高。实际上，只要是乘以或除以一个整数，均可以用移位的方法得到结果，如：
a=a*9
可以改为：
a=(a<<3)+a
6 6 、循环
(1)、循环语
对于一些不需要循环变量参加运算的任务可以把它们放到循环外面，这里的
任务包括表达式、函数的调用、指针运算、数组访问等，应该将没有必要执行多
次的操作全部集合在一起，放到一个 init 的初始化程序中进行。
(2)、延时函数：
通常使用的延时函数均采用自加的形式：
void delay (void)
{
unsigned int i;
for (i=0;i<1000;i++)
;
}
将其改为自减延时函数：
void delay (void)
Ofweek 电子工程网
{
unsigned int i;
for (i=1000;i>0;i--)
;
}
两个函数的延时效果相似，但几乎所有的 C 编译对后一种函数生成的代码均
比前一种代码少 1~3 个字节，因为几乎所有的 MCU 均有为 0 转移的指令，采用后
一种方式能够生成这类指令。在使用 while 循环时也一样，使用自减指令控制循
环会比使用自加指令控制循环生成的代码更少 1~3 个字母。但是在循环中有通过
循环变量“i”读写数组的指令时，使用预减循环时有可能使数组超界，要引起
注意。
(3)while 循环和 do„while 循环
用 while 循环时有以下两种循环形式：
unsigned int i;
i=0;
while (i<1000)
{
i++;
//用户程序
}
或：
unsigned int i;
i=1000;
do
i--;
//用户程序
Ofweek 电子工程网
while (i>0);
在这两种循环中，使用 do„while 循环编译后生成的代码的长度短于 while
循环。
7 7 、查表
在程序中一般不进行非常复杂的运算，如浮点数的乘除及开方等，以及一些
复杂的数学模型的插补运算，对这些即消耗时间又消费资源的运算，应尽量使用
查表的方式，并且将数据表置于程序存储区。如果直接生成所需的表比较困难，
也尽量在启了，减少了程序执行过程中重复计算的工作量。
比如使用在线汇编及将字符串和一些常量保存在程序存储器中，均有利于优
化
C 语言宏定义技巧(常用宏定义)
写好 C 语言，漂亮的宏定义很重要，使用宏定义可以防止出错，提高可移植
性，可读性，方便性 等等。下面列举一些成熟软件中常用得宏定义。。。。。。
CODE:
1，防止一个头文件被重复包含
#ifndef COMDEF_H
#define COMDEF_H
//头文件内容
#endif
2，重新定义一些类型，防止由于各种平台和编译器的不同，而产生的类型
字节数差异，方便移植。
typedef unsigned char boolean; /* Boolean value type. */
typedef unsigned long int uint32; /* Unsigned 32 bit value */
typedef unsigned short uint16; /* Unsigned 16 bit value */
typedef unsigned char uint8; /* Unsigned 8 bit value */
typedef signed long int int32; /* Signed 32 bit value */
typedef signed short int16; /* Signed 16 bit value */
Ofweek 电子工程网
typedef signed char int8; /* Signed 8 bit value */
//下面的不建议使用
typedef unsigned char byte; /* Unsigned 8 bit value type. */
typedef unsigned short word; /* Unsinged 16 bit value type. */
typedef unsigned long dword; /* Unsigned 32 bit value type. */
typedef unsigned char uint1; /* Unsigned 8 bit value type. */
typedef unsigned short uint2; /* Unsigned 16 bit value type. */
typedef unsigned long uint4; /* Unsigned 32 bit value type. */
typedef signed char int1; /* Signed 8 bit value type. */
typedef signed short int2; /* Signed 16 bit value type. */
typedef long int int4; /* Signed 32 bit value type. */
typedef signed long sint31; /* Signed 32 bit value */
typedef signed short sint15; /* Signed 16 bit value */
typedef signed char sint7; /* Signed 8 bit value */
3，得到指定地址上的一个字节或字
#define MEM_B( x ) ( *( (byte *) (x) ) )
#define MEM_W( x ) ( *( (word *) (x) ) )
4，求最大值和最小值
#define MAX( x, y ) ( ((x) > (y)) ? (x) : (y) )
#define MIN( x, y ) ( ((x) < (y)) ? (x) : (y) )
5，得到一个 field 在结构体(struct)中的偏移量
#define FPOS( type, field )
/*lint -e545 */ ( (dword) &(( type *) 0)-> field ) /*lint +e545 */
6,得到一个结构体中 field 所占用的字节数
Ofweek 电子工程网
#define FSIZ( type, field ) sizeof( ((type *) 0)->field )
7，按照 LSB 格式把两个字节转化为一个 Word
#define FLIPW( ray ) ( (((word) (ray)[0]) * 256) + (ray)[1] )
8，按照 LSB 格式把一个 Word 转化为两个字节
#define FLOPW( ray, val )
(ray)[0] = ((val) / 256);
(ray)[1] = ((val) & 0xFF)
9，得到一个变量的地址(word 宽度)
#define B_PTR( var ) ( (byte *) (void *) &(var) )
#define W_PTR( var ) ( (word *) (void *) &(var) )
10，得到一个字的高位和低位字节
#define WORD_LO(xxx) ((byte) ((word)(xxx) & 255))
#define WORD_HI(xxx) ((byte) ((word)(xxx) >> 8))
11，返回一个比 X 大的最接近的 8 的倍数
#define RND8( x ) ((((x) + 7) / 8 ) * 8 )
12，将一个字母转换为大写
#define UPCASE( c ) ( ((c) >= 'a' && (c) <= 'z') ? ((c) - 0x20) : (c) )
13，判断字符是不是 10 进值的数字
#define DECCHK( c ) ((c) >= '0' && (c) <= '9')
14，判断字符是不是 16 进值的数字
#define HEXCHK( c ) ( ((c) >= '0' && (c) <= '9') ||
((c) >= 'A' && (c) <= 'F') ||
((c) >= 'a' && (c) <= 'f') )
15，防止溢出的一个方法
Ofweek 电子工程网
#define INC_SAT( val ) (val = ((val)+1 > (val)) ? (val)+1 : (val))
16，返回数组元素的个数
#define ARR_SIZE( a ) ( sizeof( (a) ) / sizeof( (a[0]) ) )
17，返回一个无符号数 n 尾的值 MOD_BY_POWER_OF_TWO(X,n)=X%(2^n)
#define MOD_BY_POWER_OF_TWO( val, mod_by )
( (dword)(val) & (dword)((mod_by)-1) )
18，对于 IO 空间映射在存储空间的结构，输入输出处理
#define inp(port) (*((volatile byte *) (port)))
#define inpw(port) (*((volatile word *) (port)))
#define inpdw(port) (*((volatile dword *)(port)))
#define outp(port, val) (*((volatile byte *) (port)) = ((byte)
(val)))
#define outpw(port, val) (*((volatile word *) (port)) = ((word)
(val)))
#define outpdw(port, val) (*((volatile dword *) (port)) = ((dword)
(val)))
19,使用一些宏跟踪调试
A N S I 标准说明了五个预定义的宏名。它们是：
_ L I N E _
_ F I L E _
_ D A T E _
_ T I M E _
_ S T D C _
如果编译不是标准的，则可能仅支持以上宏名中的几个，或根本不支持。记
住编译程序也许还提供其它预定义的宏名。
Ofweek 电子工程网
_ L I N E _及_ F I L E _宏指令在有关# l i n e 的部分中已讨论，这里
讨论其余的宏名。
_ D AT E _宏指令含有形式为月/日/年的串，表示源文件被翻译到代码时的
日期。
源代码翻译到目标代码的时间作为串包含在_ T I M E _中。串形式为时：
分：秒。
如果实现是标准的，则宏_ S T D C _含有十进制常量 1。如果它含有任何
其它数，则实现是非标准的。
可以定义宏，例如: 当定义了_DEBUG，输出数据信息和所在文件所在行
#ifdef _DEBUG
#define DEBUGMSG(msg,date)
printf(msg);printf(“%d%d%d”,date,_LINE_,_FILE_)
#else
#define DEBUGMSG(msg,date)
#endif
20，宏定义防止使用时错误用小括号包含。
例如：#define ADD(a,b) (a+b)
用 do{}while(0)语句包含多语句防止错误
例如：#difne DO(a,b) a+b;
a++;
应用时：if(„.)
DO(a,b); //产生错误
else
解决方法: #difne DO(a,b) do{a+b;
a++;}while(0)
宏中"#"和"##"的用法
Ofweek 电子工程网
一、一般用法
我们使用#把宏参数变为一个字符串,用##把两个宏参数贴合在一起.
用法:
#include
#include
using namespace std;
#define STR(s) #s
#define CONS(a,b) int(a##e##b)
int main()
{
printf(STR(vck)); // 输出字符串"vck"
printf("%dn", CONS(2,3)); // 2e3 输出:2000
return 0;
}
二、当宏参数是另一个宏的时候
需要注意的是凡宏定义里有用'#'或'##'的地方宏参数是不会再展开.
1, 非'#'和'##'的情况
#define TOW (2)
#define MUL(a,b) (a*b)
printf("%d*%d=%dn", TOW, TOW, MUL(TOW,TOW));
这行的宏会被展开为：
printf("%d*%d=%dn", (2), (2), ((2)*(2)));
MUL 里的参数 TOW 会被展开为(2).
2, 当有'#'或'##'的时候
Ofweek 电子工程网
#define A (2)
#define STR(s) #s
#define CONS(a,b) int(a##e##b)
printf("int max: %sn", STR(INT_MAX)); // INT_MAX #include
这行会被展开为：
printf("int max: %sn", "INT_MAX");
printf("%sn", CONS(A, A)); // compile error
这一行则是：
printf("%sn", int(AeA));
INT_MAX 和A 都不会再被展开, 然而解决这个问题的方法很简单. 加多一层
中间转换宏. 加这层宏的用意是把所有宏的参数在这层里全部展开, 那么在转
换宏里的那一个宏(_STR)就能得到正确的宏参数.
#define A (2)
#define _STR(s) #s
#define STR(s) _STR(s) // 转换宏
#define _CONS(a,b) int(a##e##b)
#define CONS(a,b) _CONS(a,b) // 转换宏
printf("int max: %sn", STR(INT_MAX)); // INT_MAX,int 型的最大值，
为一个变量 #include
输出为: int max: 0x7fffffff
STR(INT_MAX) --> _STR(0x7fffffff) 然后再转换成字符串;
printf("%dn", CONS(A, A));
输出为：200
CONS(A, A) --> _CONS((2), (2)) --> int((2)e(2))
三、'#'和'##'的一些应用特例
Ofweek 电子工程网
1、合并匿名变量名
#define ___ANONYMOUS1(type, var, line) type var##line
#define __ANONYMOUS0(type, line) ___ANONYMOUS1(type, _anonymous,
line)
#define ANONYMOUS(type) __ANONYMOUS0(type, __LINE__)
例：ANONYMOUS(static int); 即: static int _anonymous70; 70 表示该
行行号;
第一层：ANONYMOUS(static int); --> __ANONYMOUS0(static int,
__LINE__);
第二层： --> ___ANONYMOUS1(static int, _anonymous, 70);
第三层： --> static int _anonymous70;
即每次只能解开当前层的宏，所以__LINE__在第二层才能被解开;
2、填充结构
#define FILL(a) {a, #a}
enum IDD{OPEN, CLOSE};
typedef struct MSG{
IDD id;
const char * msg;
}MSG;
MSG _msg[] = {FILL(OPEN), FILL(CLOSE)};
相当于：
MSG _msg[] = {{OPEN, "OPEN"},
{CLOSE, "CLOSE"}};
3、记录文件名
#define _GET_FILE_NAME(f) #f
Ofweek 电子工程网
#define GET_FILE_NAME(f) _GET_FILE_NAME(f)
static char FILE_NAME[] = GET_FILE_NAME(__FILE__);
4、得到一个数值类型所对应的字符串缓冲大小 #define
_TYPE_BUF_SIZE(type) sizeof #type #define TYPE_BUF_SIZE(type)
_TYPE_BUF_SIZE(type) char buf[TYPE_BUF_SIZE(INT_MAX)]; --> char
buf[_TYPE_BUF_SIZE(0x7fffffff)]; --> char buf[sizeof "0x7fffffff"]; 这里相当于： char buf[11] 查看全部

PCIe属于高速串行点对点双通道高带宽传输，所连接的设备分配独享通道带宽，不共享总线带宽，主要支持主动电源管理，错误报告，端对端的可靠性传输，热插拔以及服务质量(QOS)等功能。目前PCIe规范已经发布到3.0版本，并且在行业内得到了广泛采用，但是其功能特性还可以进一步提升。PCIe 4.0规范将于2017年初发布，其总线带宽是3.0版规范的2倍，数据传输速率将大幅提高，由8GTps增长至16GTps。另外，它引入了提高效能比的新技术，这使得它适合应用在更多各类设备中。
与此同时各大半导体厂商也相继开始开发支持PCIe 4.0规范的硬件平台，当然我们也将PCIe 4.0引入到我们的系统设计中来，近日PLDA公司开始向广大用户提供PCIe 4.0系统设计技术支持，包含的内容如下：


Gen4SWITCH PCIe4.0平台开发套件（PDK）






图1 PLDA公司推出的Gen4SWITCH PCIe 4.0硬件开发平台

Gen4.0SWITCH开发套件是一个完整的开发平台，基于PLDA公司开发的XpressSWITCH IP和XpressRICH4控制器IP，都是遵循PCIe4.0技术规范。除此之外，Gen4.0SWITCH的核心处理器采用的是Xilinx Virtex UltraScale系列FPGA以及Samtec公司开发的“萤火虫”光纤数据收发器（如图1所示）。Gen4.0SWITCH是第一款能够同时提供PCIe 3.0x8（上行）和PCIe 4.0x4（下行）通信数据传输能力的底板。




对于PHY IP资源，PLDA公司已经进行了全面的测试，提供的IP资源与大部分第三方PHY供应商的硬件设备具有非常好的互操作性，用户可以从丰富的IP资源中找到最符合系统应用需求的IP核。XpressRICH4是PCIe参数配置IP，可用于ASIC和FPGA来实现，它提供了PCIe 4.0参数配置的软件接口。







图2 XpressRICH4控制器IP内部模块

PLDA公司在其官网上提供了为期5天的免费PCIe 3.0和PCIe 4.0规范培训视频课程（链接：http://www.pldatraining.com/co ... -t... ），当然要求用户具有一定的数字总线相关知识，课程培训内容也是各有侧重，尤其是对最新特性进行了详细的讲解，如SR-IOV、PHY层（OSI标准最底层，物理层）、电源管理单元等。

丰富的PCIe PHY IP资源和PCIe 4.0 IP控制器

丰富的在线培训课程
 
 
 
来源：网络 查看全部

3D打印机软件大全