您的位置:控制工程论坛网论坛 » PLC与PAC » 控制器三十年和未来十年控制器的发展方向

常青树

常青树   |   当前状态:在线

总积分:1421  2024年可用积分:0

注册时间: 2008-09-28

最后登录时间: 2012-05-30

空间 发短消息加为好友

控制器三十年和未来十年控制器的发展方向

常青树  发表于 2008/12/14 8:19:55      532 查看 0 回复  [上一主题]  [下一主题]

手机阅读

这一阵子与各位大佬争论了半天PAC啊PLC之类的,争论到目前这个阶段感觉再争论已很没意思,想了想,还是写一个控制器的历史和未来十年控制器的发展方向来做一个结论吧。
一、历史:
1.1 PLC & DCS
控制器在七十年代开始从传统使用仪表和继电器组对应的两个不同应用领域派生出来DCS和PLC两类产品。这两类产品在初期确有相当多的不同,DCS对于回路控制这一块更为重视,而PLC对于离散的逻辑控制更为重视。当时的DCS使用通用CPU,采用软解释方式处理程序,而PLC依靠类拟于AMD2910的位块处理器处理逻辑,相对而言在系统结构上,DCS更偏向软件,而PLC更像传统的硬件继电器组。


在经过数十年的发展后,突然大家对于DCS和PLC的概念含糊不清了,因为PLC也在体系中加入了通用型的CPU,特别软逻辑PLC在指令处理原理方面与DCS并无二样,只是上位机软件的用户指令不同。不过DCS也不是原地不动,DCS在网络方面、多DPU协同工作方面、冗余方面都有了长足的发展,并大多数采用了X86的体系架构,充分利用了PC的技术成果。

那么现在的DCS与PLC的差别是相当小,从具体的技术而言,DCS有基于令牌网络的分布式实时数据库,可以通过全量通信来保证每个DPU内的映象数据都是最新的,而PLC在这一块更多的注重单机工作,就算是联网,也假定两台PLC之间只需要很少量的数据交换,所以采用的主从结构的请求应答方式通信。

在发展过程中PLC与DCS都受到PC技术发展的深远影响,特别是DCS,目前的DCS大多采用PC_BASE结构,对PC技术的吸收也相当彻底,而PLC则是在80年代未90年代的软PLC开发浪潮中大力吸收了DCS、PC的技术,特别是在IEC61131-3标准制定出来后,产生了一系列的以开发软PLC软件的公司,这些公司以欧洲公司居多,这与欧洲公司的开放软件组织成熟有一定关系,同时IEC61131-3对于日式PLC的编程方式基本是排斥的,所以相当多的欧洲企业有兴趣进军这个行业,这方面以KW、一方梯队、ISAGRAF、3S等尤为突出,这些公司对于工控软件化和标准化起到了相当重要的作用,目前的各大工控公司在开发新的软件时都会对这几家公司的产品进行深入的研究。

最初软PLC的开发大多是以PC_BASE为蓝图的,只是在后来才慢慢的加入ARM、51、AVR等CPU的支持,并一直强调开发的模块化结构,使移植变得更为容易。

目前的情况是PLC按点数和价格分成了大中小微几种不同的档次,同时按实现分成了硬PLC、软编译型PLC、软解释型PLC三种,按结构分成了背板式、模块式、分布式几种。其中大中型PLC更是在功能上加入了DCS和PC的许多功能,使其可以向上吞并一些DCS的市场,如现在很多自备电厂和化工行业都不再使用DCS而改用PLC去完成,横向来说PLC发展出了许多专用的PLC,包括数控专用、车用、设备专用等。

同时DCS也向下发展了许多有个性的产品,使其可以代替一部分PLC的产品,如淅大中控、淅大中自的某系列产品就做得比较小,只有几个回路,带显示屏,可以满足一些行业的需要。



1.2 现场总线和FCS
在软PLC出现后不久,一场新的技术浪潮冲进了工控市场,这就是现场总线,同时现场总线派生出来FCS的理念,在当初,我也是FCS的拥护者和开发者,深信在芯片能力越来越强,价格越来越低的今天FCS才是未来的控制系统。可是在实际的开发和应用过程中,我们发现全分散之后不光成本升高了,维护也变得更困难,因为所有的节点都依赖网络,而网络的可靠性就变成了一个瓶颈。这么长的网线,有任何一段出现短路或者开路都会有致命的损伤,如果采用冗余的网络和系统,则在成本方面大增。并且分散后的逻辑,会因为一个中间节点的故障导致整个系统的重大错误,当然如果用户对分布式控制理念有很深的理解当然没有太大的问题,但事实上让用户工程师理解这么复杂的拓朴结构和考虑这么复杂的现场结构是不现实的。

除非是在未来的神经元网络芯片研发方面有新的发展,可以在某一个逻辑运算节点损坏后自动由另一个逻辑节点替代,同时需要更好的基于网络的逻辑编程软件,这个软件可以对于分布式的控制器进行合理的逻辑切分,并且对任一个节点损坏后出现的状况能有合理的处理方式,或是保护或是不理。FCS发展的理想地步是只有传感器和执行器而没有单独的控制器,所有的传感器将自己的参数传给需要的执行器,各个执行器根据网络得到的参数运算并进行控制,同时将自己运算得到的中间值传给其它的执行器。因为有了中间值的问题,所以整个控制网络将变得相当复杂,每个有中间值的点都必需有合理的处理策略,理想的情况下,是当中间逻辑点出现问题后,能由任一个逻辑点进行替代,或者进行合理的保护策略。在可以预见的时间内我们将看到能满足所有要求的全新的FCS出现,在通信方面也会变得更灵活和更可靠。

目前在经过若干年的研究后,大家都形成了一个暂时的共识,那就是:根据现场的实际情况选择分布还是集中,很多情况下是一种整体分散局部集中的方式是最适合的。比方在冶金行业,很多现场使用S7-400做为主站,用S7-300做为子站,把子站分布在现场,每个子站负责一个具体的任务可者一个工段。这样一方面当网络出现问题时,各个子站可以很好的处理自己的任务,同时每个子站到设备的距离减至了100米以内,使布线和维护变得相对简单了。

现场总线的技术浪潮中有一个很有意思的情况,那就是IEC61158的制定过程,这个过程充分的反应的各大利益集团的冲突,大家为了保护自己的利益在长达15年的时间内竟然未能达成一个真正有意义的协议,最后的结果是变成了8种标准并存,后来又扩到了13种(有14种标准,但有一种退出了),标准的范围也从最初的涵盖过程、楼宇、电力等退到了只包含过程控制,这次争论的结果是当时的制定委员会的负责人在标准通过的当天宣布辞职,他说:“太多的标准意味着没有标准”。其实我个人认为做一个统一的标准包含所有行业目前来看不太现实,各个行业的关注点也不同,像一般过程控制大家可能选Profibus等,楼控可以选LONWORKS,数采和单一设备间通信可以选MODBUS等。但同一行业内实在应该制定一个统一的标准,我就常常为了联西门子或者AB的控制系统而伤脑筋。
我个人对PROFIBUS比较有感情,因为在前几年用了两个人年做了一块PROFIBUS的主站芯片,用FPGA做的,把整个PROFIBUS-DP的数据链路层的状态机完整实现了。PROFIBUS可以说是一个很好的块通信协议,对于可靠性方面处理是相当完备的,完全是德国人的思维方式,相当严谨,诊断、参数化、配置、诊断、数据交换。PROFIBUS最大的优点是状态机与通用处理器之间的多缓存结构,使通信的实时性和可靠性得到了保护。



1.3 PC_BASE
PC_BASE刚出现时也是在工控界引起了很大的反响,那个时代的控制器都是相当贵的,我记得当时一块西屋公司WDPF控制系统的250M硬盘卖5万块,而PC硬件的低成本对于大家来说是相当大的吸引力。当时的工程师分为两派,一派认为PC是为商用开发的,控制界只能吸收其有用的技术,而另一派认为PC技术的广泛应用,有如此之多的软件和硬件资源可供利用,对于控制器的标准化和降低成本有很大的好处。

在这个过程中,国内的工控厂商包括DCS、PLC和各种专用控制器都广泛的采用了PC_BASE结构来开发新产品,当时大多使用386和486,其中ICOP的386X_M6117D是其中最好的工业级386 CPU,可惜我只能买到M6117C只好改用了MAPLE的486DX4-100M。
PC_BASE在近些年的发展之中遇到了一个很大的问题,当初大家之所以选用PC_BASE是因为开发方便,特别是DOS年代和WIN98年代,大家可以在一周的时间编写出一个很复杂的控制类程序,在刚有网络的时候,大家通过BBS互通有无,当时感觉有一种一切均在掌握之中的感觉。
现在DOS使用者越来越少,于是很多的厂商在引导工程师走WIN的平台,而WIN对于底层的屏蔽使广大底层软件开发工程师感到郁闷,因为WINNT体系的WDM驱动程序开发需要用到DDK工具,就算是使用XTOOLS之类的简易开发工具又让人有一种隔鞋搔痒的感觉,让PC_BASE的开放性和方便性大大的被抵消了。同时WINNT体系的低可靠性让大多数工程师望而止步。
2.0以前的WINCE也是一个让人发狂的软件,不光可靠性差,实时性也相当差劲,让人怀疑这玩意只能用来做做显示屏,后来wince2.0出来后还好一点,但个人对WINCE还是有抵触,可能是当初吃苦头吃多了,总认为一个工控产品不适合选用WINCE做操作系统,因为WINCE的系统结构包括兼容性、开放性、图形方面的优点都是针对手持消费类产品的,如PDA之类,对于工控需要的高实时性和高可靠性实在有点不及格。这一方面linux要更差一些,因为linux是为商用电脑开发的,很多公司都在为linux进行减肥并把抢占式的调度机制强行加入linux,从而可以使嵌入式linux可以用在嵌入式的环境,但WINCE有的缺点它也都有,同时还要更严重,所以也不是一个好的选择。在操作系统方面,其实像VXWORKS和NECLUES之类的可能是一个不错的选择,因为用户类多是工业方面的,对系统的可控制性比较强,如果是高要求的开发者还可以买源码,这样如果操作系统内有问题就可以自己调试,我们就发现NECLUES操作系统的8019驱动方面有问题,主要是实时高速通信会有堵塞的问题,后来发现这一部分代码是从linux的源码中拷过来的,所以linux也有类似的问题。

对于PC_BASE更要命的是低档X86的配套芯片都已停产,包括DRAM等,使大家想接着使用386、486、586都不可能了,(我一直很喜欢ICOP的M6117,可惜现在DRAM真是买不到新货,全吃库存了),除非使用旧芯片,,当时我们花了三年多的时间试用过多种不同类型的中高档CPU想选一款理想的处理器而不可得,那个时侯民品方面的工程师都将目光转向ARM,因为大多数情况下在WINCE和linux上开发X86的软硬件比在ARM或者AVR处理器上开发类似的程序难度差别不大,而且ARM的成本比X86要低很多。我们试用了几种ARM后(当时AD公司的工业用ARM还没出来)感觉ARM用在工业上面不特理想,大把显示、音频、VGA、以太网MAC之类的功能都在工控常规平台内用不上,而且ARM的抗电磁兼容方面也是一个头痛的问题,对于一般要求的2000V快速脉冲还可以满足,但再向上走就很难做到。

在PC_BASE发展过程中大多数厂商都遇到了PC_BASE单体成本高、需要用户有较强的开发能力的问题,使PC_BASE的量很难做大,对公司的技术支持的能力和要求也很高。为此很多工控机的厂商都找到了像KW、infoteam、ISAGRAF、3S这样的软逻辑开发商,利用工控机或者PC104+IO板卡来组成一个控制平台,这种控制平台最大的优点在于可以支持现有PC的各种资源,使监、控可以做在一体,缺点主要是从小PLC来说,从本太高,从中大型PLC来说点数又太少,同时抗干扰和抗振动方面存在许多架构性问题。



1.4 PLC、DCS、PC的交叉点:
在各种现有技术的发展过程中,因为IC技术、通信技术、软件技术的高速发展。PLC、DCS、IPC在近几年出现了相当多的交叉和重复,基本上变成了有一部分PLC看起来更像DCS,而一部分IPC改头换面之后其实与大多数的软PLC并无二样,也采用模块化结构,也使用IEC61131-3的五种语言,在使用上面比大多数的PLC更加容易更加偏软件。

这些年经常见到一些朋友问倒底DCS与PLC的区别是什么,IPC+软逻辑之后是不是PLC?

这个问题真是一个很模糊的问题,因为差别实在是太小了。我曾经研发了五年的DCS又研发了四年的PLC,其中更多次使用IPC+软逻辑开发过PLC的产品,所以从我们做研发时的定义来分别这几种产品吧。

DCS:
DCS原来设计主要是为顺序控制开发的,一般循环的速度要求不高,大多数在50ms~1秒以上可以设,但DCS应用的场合主要是电厂的主控、化工、造纸等,这些场合是一些比较复杂的模型,需要很强的模拟量运算能力,同时大多数DCS都会针对不同的行业开发不同的功能块,使用户在使用时不需要自己用PID之类的算法做控制,而是更抽象到了模型或者回路这一层。

另外DCS的用途中点数通常比较多,很多大系统加上中间点可以达到20万点以上,硬IO点数也在数万点之多,如果用一台控制器当然是很困难的,所以大多数DCS在多DPU协同工作方面有很强的能力。

每一个DPU内均有一块实时数据库,实时数据库按站数和内外分成多块,每个站都用广播方式将自己的变量全量发送出去,同时每个站都会接收和更新其它站广播过来的全局变量,这样使每个站都可以实时的得到其它站的数据,从而使DCS可以很好的控制一个大系统。

PLC:
小型微型PLC倒没什么冲突,因为结构和低成本的原因与其它两类产品完全不同。而中大型因为大量使用PC_BASE技术使其与DCS和IPC+软逻辑基本上没有差别,只是因为这些厂商大多之前就是PLC厂商而且客户群都是PLC的客户,所以他的产品也叫PLC。

IPC+软逻辑:
在十几年前美欧的几个专家在这个问题有过一段很长时间的争论,围绕了一个问题是IPC+软逻辑如何实现才是合理的,因为当时主要有几种声音,一种是完全反对IPC在控制中的使用,因为显而易见的可靠性问题,和操作系统的兼容性与可靠性如何并重。另一种是完全支持IPC在工控中的应用,并认为要完完全全的使用标准的PC软硬件,这样才可以使兼容性和开放性的优点充分体现。最后一种是一种折中的方案,把PLC插入IPC内,做为IPC的一个板卡。在实现上面也有这么几种方案:

方案一:标准操作系统,包括WINNT(含XP、2000、NT等)、linux、DOS,加软逻辑软件

方案二:标准操作系统加PLC卡,这样当电脑死机时控制不会受影响,重启电脑并不影响PLC,同时PLC与PC之间通过共享内存或者双口RAM进行数据交互。使其可以有PC的开放性和各种资源同时可以保证控制部分的可靠性。

方案三:重新设计的硬件系统如模块化结构再加上软逻辑软件,使其硬可靠性与PLC完全相同。

从上面的方案一看,在一些特殊的应用场合有一部分市场,主要是在运控、图像、显示方面有其很大的优点;方案二是一个很保守的做法,但成本方面比较高;方案三其实已经是一个PLC了。



1.5 数控系统
数控系统的实现目前也有好几种方案:
方案一:通用PLC带数控功能
这对于需要逻辑控制又需要相对简单的位置控制的用户来说是一个很好的选择,无论是成本和开发都有很多优势,不过通用型的PLC大多没有联动和插补指令(部分产品有),并且不支持G代码,无法与CAD软件进行接口。

方案二:专用的数控系统
这种系统有很多使用PLC的平台加DSP加FPGA实现,高档的这种系统可以与CAD软件无缝联接,从CAD导出来的G代码在经过编缉或者不需要编缉下载到控制器内就可以做出各种对应的动作出来。该种系统对于多轴联动控制和插补G代码均有很强的支撑能力,同时一般带有显示,可以在运行时同步在显示屏上显示运动的轨迹。

方案三:IPC+数控板卡
这是国内数控厂商的主要形态,有灵活性高的优点,但很多系统不支持标准的G代码,而是要用户使用C、C++语言或者VC去编写对应的控制程序,由板卡厂商提供函数库。当然目前大多数情况下是由数控厂商代用户完成这一部分的编程。

这种开发方式的优点是显而易见的,厂商的开发成本低,灵活度高,但是需要厂商提供相当多的技术支持,如果客户数量大后很难有足够的支持能力,所以这类厂商大多都在开发通用的数控平台,并仍然使用IPC平台在上面开发通用型的数控系统。



1.6 楼控
楼宇控制可以说是一个很好玩的行业,价格奇高,但功能却不并复杂,所以现在有很多工程商在使用小点数的PLC组网代替DDC,但在易开发方面相对要差一些,主要是楼宇本身是高利润行业,大家对一个点近千元的价格并不感到无法承受,只有当楼市价格下降竞争大了才会有可能重视成本方面。

我个人认为未来楼控很难做为一个单独的控制器种类存在,而会被其它产品给吞并。

1.7 数采
数采行业因为受到了GPRS、GSM等业务的影响,正出现一次比较大的变革,特别是在远距离方面,传统的MODEM、RTU方式正受到很大的冲击,在我们经手的很多环境监控、管道监控、路灯节能、水文监控方面很少有客户能经受GPRS DTU的诱惑。DTU的基于网络和透明通信方式深受大家的喜爱,只是目前DTU的价格相对而言还是比较高,如果能掉到GSM MODEM的价格就比较合适了。



2 未来的控制系统
前面讲了这么多历史,下面我们来看看我心目中的未来控制器。

在经过FCS和现场总线的浪潮过后,各大公司好像都累了,这几年大家都在底头为下一代的控制器做各种研发和准备,在这个过程中,我们与东芝、AB、思博等公司进行了比较深入的合作和交流同时也有了一些自己的想法:

将来的控制器将会分为以下三类:
第一类:
单芯片控制器:
单点价格在10元左右,支持可编程,可以带现场总线或者网络。把位块处理器、通用处理器、存储器、均合成在一块芯片内,只需要加上很少的外部电路就可以实现一个可编程控制器的功能。

西门子的LOGO无疑是这种方案的一个实验者,不需要太多复杂功能,成本要相当低,并一定要可以联网,这样单点的PLC将是一种比较现实的产品。

这一部分的产品目前已经有很多国内外的厂商在做这一方面的研发工作,最大的一个问题在于取舍,那一部分功能是不需要的,那一部分成本是可以减下来的,是否能很清晰的定义和标准化这类产品,使其变成一个和低压电器类似的常规电器,并可以结合FCS的思想把这类产品做到未来的智能家居中去,这样一方面量可以足够支撑成本的下降,也可以加速这种小控制器的标准化。

很多朋友可能会想到万可和智国的产品,万可的产品现在价格并不存在这种优势,同时过份的分离使其成本很难达到要求,而智国的产品只是将IO接口、继电器、电源放到外部从而使其成本显得比较低,实际上加上各种隔离接口后在同样可靠性要求下,其成本并不低。
所以个人认为这一部分的产品需要一个比较长时间的标准化和一个大的市场的冲击,个人认为可能是在下一代的智能家居方面,很多朋友都找我谈过可不可能做一个很低成本的带无线通信的很少点数的可编程控制器,用于智能家居和智能楼宇方面,但我一直忙于现有产品的研发和市场推广工作,无力再去开辟一个新战场。当然我相信在国内控制器研发日益成熟的今天很快就会有人把这种产品开发出来。

未来每个灯或每一组灯带一个可编程控制器将不是梦想,我想在未来的三五年之内将可以看到这一类产品的大放异彩。



第二类:
多控制系统的通用平台:
在一个小体积的前提下,有PLC、DCS、IPC、数控等多种控制器,各种控制器之间可以通过光纤或者超高速的串行总线也可以是背板进行互通,大家可以共享数据和信息。IO模块通过串行总线或者背板与CPU进行交互。

这种结构必需是一种积木式的结构,大家可以在一个统一的结构和平台上按自己的需要选择不同价格的控制器、IO模块,比方说你使用的环境是设备控制,不需要复杂的运算,你就可以只选用PLC单元,而半年后,如果用户需要增加历史数据库和监控,那么用户可以买一个PC单元加入现有的控制系统,并通过一些设置和编程从而可以实现他需要的功能,而不需要在边上加一个电脑,当然这个PC单元是模块化结构的而不时通常的IPC。

这种控制系统最核心的是一个数据的交互和共享,这包括编程环境的整合和开发工具的完备,同一个变量必需在不同的控制器内是同样的数据结构,比方说变量A是由PLC产生的,但DCS和PC端也需要使用,那么应该可以在同一个集成的开发环境内可以从DCS的程序中看到同样的变量A,同时在PC端的数据库和HMI软件上可以使用到变量A。同时PC上的分析软件和优化软件也可以在同一个开发环境内对控制系统的工艺和算法进行寻优。

PAC是当前这种发展的一个子集,我个人更希望PAC按NI的方式发展,因为那样才能显示出一个新品种的特点来,否则与传统的软PLC并无二样,就变成了一个纯口号了。

这个地方一定要强调,这种多控制系统的通用平台这是一场软件的革命,从硬件角度来说,目前已有相当多的控制系统是带有这些特性的,比方说东芝公司的未世代综合控制器等,他们在同一个背板总线上可以插入三种不同的控制器,分别是PLC、DCS、PC,在软件方面他们也做了相当多的工作,使其可以很方便的进行跨控制器交互。软件方面的交互和工具的完备需要一个较长的发展时间,大家可以拭目以待。

说到东芝公司,日本人的团结使我感到吃惊,目前三菱、横河、东芝、日立有一个共同的控制系统研究所,这个研究所开发出来的平台和软件可以供这几家公司共同使用,东芝的负责控系统开发的苋总工也是一位相当有远见的专家,与其多次交流均很受益。使我也相信了大多数日本人个人并不坏。另外苋先生与德国infoteam的布兰德博士和KW的老总都是白发苍苍的长者,让人感到敬佩的是这几位长者对于技术的执着和深入,而国内我见到很多小伙子二十几岁就开始担心三十岁了能不能还干技术是不是要换行做管理或者市场,工控就像酒一样,时间越长越有味,在中国老一辈还在前线的工程技术人员少的原因主要是因为文革和改革开放初期的全民皆商给破坏掉了,起码我相信如果不出意外,我到60岁都还会对技术充满兴趣。



第三类:
专用控制器:
我和一位朋友做过一个总结,一个产品或者装备,如果全国的年产量超过1000台,未来都会有人开发专用控制器,这不是悲观,而是因为成本和竞争造成的,比方说注塑机,在以前大多使用PLC,而现在大部分都使用专用的控制器,再比方说回流焊,这以前是西门子S7-200的市场,一套PLC加一个PC,现在相当多的厂商在用亚当温控模块或者IPC加板卡的方式做各种尝试,同时已经有不少厂商用单片机开发了专用的控制器。再比方说电梯,这是三菱传统的市场,现在被专用控制器挤掉了一大半的市场,这只是说这几个行业成熟了标准化了。

但是目前的专用控制器实现方式有其局限性,如果这个行业的产品都是标准化的,用户没有多少非标的需要,那么问题不大,可是如果有相当一部客户需要做改动,那么选择这种方式就不是太合适了。

这就是我们现在推崇的利用通用可编程平台开发的专用控制器,也就是用PLC的平台开发专用控制器,这样成本上面比单片机的方式高不到100块钱,但是可以享受PLC的可编程优势对用户的需要可以进行各种修改,同时可以享受PLC标准的各种接口,比方说网络、通信、数控等,而不需要再去重新开发这些功能。更重要的它的结构是按装备生产厂商的需要设计的,并且可以带液晶或者数码管的显示,用户不需要硬件和多余的点数都被去掉。成本方面比通用的PLC更有竞争力。

未来的控制系统最主要的工作在于软件和标准化方面,如何打破各大工控厂商和各大利益集团的壁垒是最困难的事情,希望不要像IEC61158一样十五年出来一完全无用的标准。在这一方面中国的厂商有其先天的优势,因为是后进份子,所以没有包袱,可以选择任何对自己有利的结构和技术,同时传统以来中国产品低价的习惯也会起到很大的作用,先是量变最后是质变!但国内各厂商如何进行合作,通过什么样的方式鼓动大家,使大家愿意放开短时间的小利而放眼全球的大市场是一个很困难的任务,这需要有魄力的企业家和有能力的组织者,我与好几家国内的控制器生产厂商领导谈过这个问题,大家都表示赞同,但因为大家都处于初创期,没有足够的资金和精力来处理这个事情,当然具体的方案也需要比较合理。

3.0 结尾
前几天因为看了PAC几位朋友的论点,不是很认同,所以争论了一场,见几位朋友都已经动气,在这里,如有得罪这篇文章就算是赔礼了。
真心希望工控论坛能吸引更多的控制系统的研究人员上来,这样可以提升整个坛子的水平,也希望大家在讨论技术时要以技术为重,你可以有门户之见,你可以有自己的观点,但不要上升到对个人的攻击。起码在我就很喜欢我们的研发人员互相进行辩论,就算经常是谁也说服不了谁,但其实在争论之中大家都在受益。
1楼 0 0 回复