tag 标签: 项目

相关博文
  • 热度 2
    2016-5-23 10:02
    211 次阅读|
    0 个评论
      课程摘要:         一体化联合作战环境下的武器装备系统,面临着庞大的系统规模和需求不稳定等多重困难,传统的面向过程的结构化系统工程方法已经无法完成对系统的描述,必然要求工程思想和方法学的变革。         美国从上世纪90年代开始研究新的系统工程思想,总结了以C4ISR为代表的复杂军事大系统的多年开发经验,在C4ISR AF V2.0的基础上,美国国防部根据国际系统工程领域的技术进展和美国最近20年来的军事系统研发经验,先后在2004年1月、2007年4月、2009年5月颁布了DoDAF体系结构框架标准V1.0、V1.5、V2.0,作为指导所有军事工程项目研发的系统工程方法论。         针对基于体系的武器装备论证的研究和应用,使得武器装备系统研制过程更加规范、高效和成熟,有效地改善原有工作流程,明显提高武器装备研发的质量与效率。 邀请对象: 航空、航天、兵器、船电等感兴趣的客户 课程时间: 5月26日 周四晚19:00-20:00 课程主题: 一体化武器装备体系论证 讲师介绍:         王晓安,现任恒润科技系统工程部经理,专注于系统工程/软件工程在国防、汽车、轨道交通等领域的咨询和研究。在基于模型的体系工程、系统工程、需求工程、复杂嵌入式研发平台建设等方面拥有丰富的经验,在多个大型系统工程咨询项目中承担过架构咨询师和项目经理。 活动流程: •  19:00-19:40 讲师微信演讲 •  19:40-20:00 自由提问 •  20:00以后  大家自由交流学习。 报名方式: 方式一:点击文章上方“经纬恒润”,关注恒润官方微信公众号,回复“微信号+姓名+单位+联系方式”,微课堂客服号将会添加您的微信,将您拉入本期微信讨论群。 方式二:或经由您认识的恒润技术或销售人员直接拉入本期微信讨论群。 如果您感觉该主题还不错,请帮忙转发给您的好友,参会有惊喜哦! 联系帮助: 电话:010-64840808-5280 邮箱:market_dept@hirain.com
  • 热度 23
    2015-10-19 22:57
    7498 次阅读|
    16 个评论
          曾几何时,也不知到当初自己默默的走向了硬件嵌入式的道路,或者当初的兴趣只在那么一瞬间,而以后的路却很长。 记得是刚上大一那会,隔壁班的班长到处来宿舍宣传,参加机器人了参加机器人了,然后那会可以说很多人在这方面基本上都是渣渣。让自己印象最深刻的是二楼有个同学在这方面基础很扎实,因为他刚来学校的那一年他表哥留给了他很多元器件,价值应该在四位数以上,这里我暂且称他为 A 同学。那会就很羡慕他有如此多的元件,加上他喜欢音乐我也很喜欢所以很自然的成为了朋友,而在后面的年代了,和他在一个团队下面共处,有着一个长达 6 年的友谊。后来我参加了 MCU 的培训,他也是,而且入门比我还早,当初学习的东西都是皮毛,没有一个具体的应用,根本就不能成就什么,这是我们后来的老师的原话! 之后他跟了学习以为硬件很厉害的老师,因为这老师他很多设计上面的事情都亲力亲为,就算哪个电路的电容大了小了也会指出来,甚至自己动手。因为他曾是 DIY 爱好者,家里有很多稀奇古怪的电子设备,也就促使着我们同样也是 DIY 爱好者,特别是 A 同学后面很多事情都是自己在做创业的项目,家里买了个各种大功率音放、示波器、电源等仪器,后面也见证过他在外边接了几个项目。        自己当初并不认识我的导师,无意间要考试了,听班长说有个硬件高频的导师要来讲解下内容,然后自己去听了,也就是那一堂课,我认识了此生对我恩重如山的导师!虽然多年过去,但是自己依旧记忆深刻,那一堂课, 1 班有个学霸不懂的问题上课当众问他,然后自己抢先回答,说你这都不懂吗?然后讲解了自己的见解,这时老师说:“你这小子,不错!”。也许就是这样自己给老师留下了深刻的印象。之后因为同学 A 已经在他手下做事,鉴于和 A 同学关系不过我没有绕弯子,因为那个时候处于人生迷茫期急需有一个德高望重的老师来指点自己前程,直接和 A 同学说让他带我去老师那,其他的我自己说。第二天我就去了他家,同样没有拐弯抹角,他答应以后带我。就这样我成为他的学生!当然同学也要感谢身边众多师兄师姐的帮助,以及所有同学的互助,老师的教诲,学校的支持,都让我们这些年难忘!          在我老师的指导下,我那个时候除了上课只要有半天的时间就会去他家,而他有空就会知道我画原理图, layout ,如何看 PDF 查出最关键的指标参数,如何参考最经典的方案,总之只要是涉及到方案的东西他都会教我,当然我们都很有默契,他那年手下带的学生有 8 个左右,最后都是参加竞赛出身,都做过大大小小的项目。同样因为老师自身本来就喜欢动手,培养的我们当然也是自己喜欢设计出东西的。         带我们的第一个项目是基于原子频标的一个高精度测量频率稳定度的项目。这个项目 A 同学在里面的角色还比较重要,这个项目后面参加了挑战杯,最后由省特推了国二。 A 同学因此在大四时候保研。         当时做的首板,主要的程序量是为很牛的师兄编的。后面参加国赛时候有加强版,当时自己也学了很多类型 MCU 来做控制,而更多的是硬件设计,最初每天都画库,老师给了自己很多库,但是不够所以得自己建。那会自己已经做了很多类型的 opa 、也做过车、做过往届电子竞赛的题目。平时没事就呆在实验室或者遇到问题就去我老师那里,一过就是一年,而那一年遇到自己在以后道路上的搭档同学 B 。他同样有着鲜明的个性,做事绝不拖沓!我们成为搭档也是有说有笑一同好几年,也合作过,同样两个人 DIY 是个什么概念?他写程序我做板子。同学 A 有时来指导指导我们。直到后来参加一个比赛 ------ 起重机的控制系统。主要我和同学 B 负责,做了一款模拟的,还有我老师到我们去现实产地中做过大量的实验。回到学校再改进,再实验。虽然这个创新的项目没有达到我们想要的目的,但是它的影响力让我们更加相信有美好的未来。            在这个项目里面整个团队花的时间还是挺多的,解释下项目 ---- 起重机因为放下物体的那瞬间损耗很多能量,我们做的就是利用超级电容来收集下降的势能而将这些能量存储气起来,等需要耗能的时候再将能量提供出来,以节省总 电源的耗电量。总共效率最后测试的时候能够达到 20%+. 具体的数据不记得。后来多次在现场测量。         下图是我们做的模拟的一个系统,说白了就是简化现场,为了参加比赛给别人做的演示。 同样利用下降的势能收集能量。 箱子里面全部是电路的控制部分。         这个创新项目在市场中的应用是好的,但是最终依旧没有达到我们的目的。而在平时的日常生活中其实自己很少接触这类大功率的东西,说起来自己对于小信号更是情有独钟。而我老师也时常教导我们,没事的时候要多学习,看看书,特备是竞赛类的书籍,这样借鉴别人的才能使自己变得更强,至于其他方面,我会尽自己能力帮你们。所以平时画板子,腐板子,做小东西成了家常便饭。         这是一款纯模拟的板子,期间用了很多高速OPA,用来做选择频率的。         这是腐蚀的一块MSP430的板子,后面这板子能用,用来做控制FFT+数字光感的一个仪器。这个小板子做了一天,最后还在网上开了一块小板子。当时做板子的初衷就是能够多DIY一些东西,没想到结果每几天就做一款板子,做的速度越来越快,这位后面的参加比赛以及加快很多项目提升了进度,也打下了铺垫。         另外还有很重要的一点,我老师也时常提醒我们,有动手能力是不够的,要懂原理,因为没有理论的支撑,再好的动手能力你也就是个焊工!所以!重要的事情说三遍!!!多看书!多看书!多看书!!!   PS: 我的故事虽然微不足道,也许很多人比自己经历过更深刻的事情或者比赛,但是依旧希望很多人在学生年代多接触一些技术上面的事,多看书,少玩游戏,让未来的自己感谢如今的自己。   觉得我写的不过或者有什么需要交流的请留言。另外今晚有点晚,明晚再更新。。。
  • 热度 2
    2015-2-11 09:19
    307 次阅读|
    1 个评论
    尊敬的客户: 羊年未到,祝福先行。愿亲爱的您在2015年羊年: 生活喜乐羊羊, 工作如羊吃苦, 事业如羊中天, 爱情似羊缠绵。 做人羊眉吐气, 家庭吉羊如意, 心情羊光满面, 健康羊羊得意。 愿您羊年,享羊福喝洋酒开洋荤!     【温馨提示】     为了避免春节假期导致的案件延误,对于正在进行中的项目,请积极配合我们的工作,以便在春节前顺利结案。如有任何新项目测试,请联系我们的业务精英,以便赶在年前准备相关事宜。     我们全体业务和工程人员,会加快项目进度。具体项目进度可以联系各业务代表,谢谢!   北测检测2015年羊年春节假期安排:2月17—25日休假,2月26日(年初八)正常上班。   北测检测全体职员敬上
  • 热度 6
    2014-11-10 14:59
    746 次阅读|
    4 个评论
            前几天,学弟说他们有在做一个关于逆变器的项目(学生项目不是很复杂),说有个问题困然了几周;然后把他们抓的波形给我看,原来是波型在波峰或者波谷失真的问题。Ps:对于SPWM的产生方法很多也很成熟:可以用用专门的硬件芯片,程序控制也能做的很精确了,选择的算法也很多。        可能也是受到“拿来主义”的影响,在我问了他几个问题中,他都有点模棱两可,此处省略N个字,一步步引导之后确定是软件的原因,给出了他一些验证试验的方法;由于自己有过这些经验之后点出了他们在实验过程中出现的问题,以及思路上的一些不足。         果然第二天问题解决了,他也觉得收获很多,说有种恍然大悟的感觉,看到他们的努力,坚持与进步自己还是觉得很欣慰的。        之后又谈了谈“实验室文化”的延续,给他们提了很多意见,从他们的话语中让我感受到了,只要学到技术就可以了,其他可以都不管,比如实验室不同成员之间衔接,合作,以及氛围的营造,再往后里讲就是氛围的传承等等;这些都让我很吃惊,一直都有这麽一些流传对于很多工程师大家都觉得自己天下第一,喜欢自己一个人单干,觉得这样学到的东西会多,可以说就是死抠技术,并不善于合作以及管理与规划。这些都与我自己认识的有很大的不同,技术应该说只是自己学习过程中的一部分,但不应该是全部。如果太看重技术又会固话思维,如果在学习技术的过程中腾出一些时间来想其他的事,可能又怕自己纳下一些东西没学。所以这样的问题是很矛盾的,但并不是不可解决,在面临这些处境的时候,更应该跳出去思考问题,改善自己的思维与认识。跟他们讲了之后,得到了他们的赞许,也希望他们能将实验室的学习氛围能够一批一批的提高。         对于“拿来主义”对于做项目来说,有利有弊,能在一定程度上推进进度,但是如果单单只“拿”搞出个结果,但是不去梳理清楚过程、原理的话对开发展来说就缺少了思考和提升的过程,想想应该很多工程朋友都有过这个过程。可能是思维定势吧,往往在这种情况下,我们都会选择把思维停在这个层次了,当经过一定积累之后慢慢就会改善很多。只有自己懂了跟多之后,才会想的更全,并在否定与成长的过程中循序渐进,想必这就是学习吧!!!它需要饱满的热情、以及自己的坚持。         想必这些道理大家都懂,只是说大家感悟的深与浅;对于学习三分钟热度是不能够解决的、也没有速成的方法,坚持与天赋都很重要,但是真真需要凭天赋做的也不是我们这种级别能够接触到的。所以能够循序渐进的坚持就好了、能够脚踏实地,不要一味追求“高精尖”,往往自己连基础的都没弄明白——这也算对自己的训诫吧。
  • 热度 6
    2013-12-28 10:27
    1678 次阅读|
    5 个评论
    开发中的新理解——成长在2013 今年在公司里,收获很多。从很多方面,都一个新的认识。因为参与公司的几个项目。有的是维护原有代码,有的是从需求开始,从0做起,有的做了一半,因为调整不做了,有的刚开了个头,因为其他项目需要暂停了。每一个项目,做的程度都不一样。但是每一个项目,都让自己对于完成一个项目,有了更深的认识。也慢慢在改变自己以前那种学校式的研发状态。由一开始想从每一个项目中学习新技术,到想办法确保每一个项目都能按照预期按时结束,做出能够交付的稳定产品。而这本身也是一种学习。   /* ---------------------------------------------------------------------------*/ 年初,公司接到一个项目,给客户提供一套软硬件系统。其中自己负责的部分,需要对一年半前的代码进行维护,修复其中的Bug。对于这份代码由于是一年半前由两个人写就。当维护的时候,第一件事就是怎样读懂代码,找到能入手的地方。当开始研读代码的时候,发现全局变量定义实在是多。一个.c文件中,多的时候就会有二十几个。而代码之间的耦合,造成全局变量的定义和使用可能在几个.c文件中。函数间的参数传递,有些就是直接用全局变量实现的。代码过长的函数,就有好几个,有的函数一个switch就会有200行以上。当时,读到这些代码的时候,第一反应是一定要把这些当时认为不好的代码全部修改了。确实一开始也这样做了,以为只要费些时间就会弄完,然后,有了一个熟悉的代码理解也会更快。   但是一段时间后发现要改的地方真是很多,而且测试起来也很难办。因为是嵌入式上的程序,很多地方都要手动去一个个测试(当时如果知道了《重构》的经验与教训或许不会那么大刀阔斧的来)。测试的过程十分麻烦,而且会造成有些地方测试不到。由于源代码底层代码与应用层代码耦合比较厉害,如果有改动,底层的不稳定会导致整个系统的不稳定。而这个在最后发现了。由于中途临时需要交付一个Release版本,有些地方改了还没有测试,只好将没有测试的地方恢复。这样代码中就出现了改了一半的代码。由于自己在修改的过程中,也没有遵循原有代码的代码风格(由于原有代码tab键与空格混用,看不出风格,变量名也比较随意)。也有些地方遵循自己的编程习惯,修改了代码中存在递归的代码。   最后发现,程序并没有比原来更好理解,耦合性还是很高。在后期考虑到硬件有一个元件已经停产,所以建议更换新的模块。更换后,由于对于新的模块不是十分熟悉,导致出现了比较严重的问题。这个事后自己反思的时候,认为当时提的一个很错误的建议。在项目的后期,已经没有多少时间去测试稳定性了,而此时却将以前稳定的元件替换掉,而换新的元件,测试时间又没有那么多。直接导致了不稳定的存在。事后,也确实因为这个元件,导致了第一批出货出现了返修。为此,连续三个周末在公司解Bug。   整体的维护中,虽然改善了原有代码的的Bug,但是却也引入了新的Bug。在这个过程中,前期也是自己对于代码维护的理解有偏差。如果说重构,也要是用到的地方进行重构,而不是对于很多地方重构。更不应该在项目后期,进行元件的替换。如果说维护是为了保证产品的稳定性,那么就要在最小的范围内做修改。尽量避免修改不需要修改的代码。但是,这里边涉及一个问题,怎么判定那些是需要修改,那些事不需要修改的?有些容易判断,但是有些就十分模糊。   这里还有一点,如果说尽可能减少修改的地方,那么对于维护者而言是否会接受这样的概念?对于一个初做的人,总会想多做一些。是得过且过,还是精益求精?这个或许《重构》最后的一个建议很好“使重构成功的不是前面各种技术,而是这种节奏”,懂得重构是在于“可以自信地停止重构”。但是这种节奏的获得需要有大量的实践才会获得,这种自信也需要从实践中一点点获取。在此次维护结束后,想要找到自己在维护的过程中犯下的错,以期以后不会在同一个坑中栽倒第二次。如何在以后的类似工作中做地更好,在反思了一些以及看了一些书后。认为维护过程中有几点是严重犯错的地方: 没有做到对于不必要的地方不修改; 缺少质量管理的观念。 经过这次维护的经历,得出了以下几点: 确定code style,编写易读性代码,代码可读才会使维护更容易; 使用lint工具检查代码; 积累重构; 注意C的安全性与非安全性; 建立代码质量的观念,建立产品质量的观念;   /* ---------------------------------------------------------------------------*/ 年中,接到另一个项目。和前一个项目完全不一样,这个是要从零开发。自己负责软件中的一部分。初期由自己做设计初步的通信协议,以及通信机制。在开发过程中,发现由于客户不了解元件的特性,推荐的元件型号不满足客户自己的要求。于是,进行了元件更换。在新的元件上,很容易做到客户要求的指标。这些完成后,要给客户提供一批样品进行测试。这个过程中发生了一些意外。试产的第一批在使用测试程序后,发现有一半测试不合格。经过测试分析,发现硬件的模拟部分不同PCBA之间存在差异,原有程序的初始值在差异较多的时候会出现异常。于是将程序的初始值,修改后重新测试发现大部分输出都正常了。   在后来生产的过程中,发现由于实际要装配的东西很多,装配的过程很多,而选择的外壳内部空间较小,造成内部空间很紧张,给装配人员实际造作中带来很**烦。直接的影响就是装配的效率偏低。在催促他们提高装配速度的时候,也确实很难提高速度。测试的项目很多,需要时间。外壳的尺寸和元器件之间内部空间的限制,以及外壳螺丝都成了影响的一个因素(采购的外壳,有些螺丝因为攻丝有问题,导致螺丝装卸较困难)。元件多,要装的步骤会相应多一些。   在这个过程中,反思为什么会出现这样的问题。   首先,软件上的设计一开始没有深入了解具体的硬件情况,导致软件上的参数设置和硬件的偏差配合不上很好。对于具体要应用的场合了解还欠缺深入。在提供给测试部的程序将测试程序与正式程序分开,导致测试人员在测试完成后还要重新烧录正式程序。如果当时,自己在设计程序的时候,将测试流程包含在正式程序中,通过特殊条件触发,能减少测试人员的测试时间,提高他们的速度。同样,在需要的一些测试环节,或许还有可以提高的地方。   其次,选择的外壳和连接线,PCBA之间配合不好。这方面如果考虑多一些,装配人员就能省下来很多时间,提高装配效率。也不会抱怨产品那么难装配。更降低了装配的主动性。   在这个过程中,深深感受到保证每一环正确的重要性,即使有一步缺失都会造成最后产品生产的进度与性能。   /* ---------------------------------------------------------------------------*/ 后来又根据需要接手了两个,由于预期的调整,每一个都做了有一个月左右停下。   /* ---------------------------------------------------------------------------*/ 在这个过程中,慢慢明白了,在一个团队中、在开发产品的工程中最重要的不是技术问题,因为对于一个开发者而言技术通常不是问题。技术可以一点点习得,技术可以google,可以研究,可以向别人请教。而一个开发者通常欠缺的是——建立项目的概念,进行有效沟通。项目进行过程中,每一步都是由有效的沟通驱动。了解需求,团队合作,协同开发,测试反馈,生产反馈……。如果这些过程中,有地方没有明确理解对方表达的意义,或者没有明确表达自己的意思,都会造成整个项目开发上的delay。没有正确了解需求,开发出来的将是一堆无用的代码;没有团队间的有效沟通,开发中成员间将会互相掣肘;没有有效的测试反馈,开发出来的将是质量无法保证的程序;没有生产部门的有效反馈,开发出的有可能是不利于生产的产品。同时建立一个项目管理的概念,也是十分必需。如果将项目广义化,我们工作中接到的每一个任务,对于我们自己而言都是一个项目,我们开发结果的使用放就是我们的客户,而我们自身就要做好对于这个任务的管理。保证给我们的“客户”是高质量的产品,只有每一个环节都有高质量的产出,才会做出最后高质量的产品(产品质量符合木桶理论,注1)。由此而言,作为一个开发者,要关心的不仅仅是技术,也要关心于有效沟通,建立项目管理的观念,将它们用于平时的工作。技术可以保证我们出色完成当前分配好的工作,但是并不能保证我们提供一个高质量的产出,更不能保证项目的顺利完成。所以,技术很重要,但它不是全部。   /* ---------------------------------------------------------------------------*/ 整体而言,这一年在公司经历了很多。从技术,到其他感受也很深,收获也很大。 从一开始想要探究代码,到现在对代码三思而后行; 从一开始想要钻研,到现在工作上enough is good; 从一开始不知何为代码安全,到现在编程时刻将代码安全放在心头; 从一开始不知如何修改代码,到现在试着找找重构的节奏; 从一开始只知开发,到现在从测试、生产、使用的角度考虑设计; 从一开始把代码管理当做备份,到现在建立branches,打tags,查看版本graphic; 从一开始不会lint,到现在用lint工具检查C代码; 从一开始对项目一知半解,到现在慢慢建立项目管理的概念,指导平时的工作; …… 这些的这些,记录了一年的酸甜苦辣,记录了一年的变化。走过,“回首向来萧瑟处,也无风雨也无晴”,留下的是——成长。   /* ---------------------------------------------------------------------------*/ 注: http://forum.eet-cn.com/BLOG_ARTICLE_18255.HTM 关于合作。 http://forum.eet-cn.com/BLOG_ARTICLE_18978.HTM …… http://forum.eet-cn.com/BLOG_ARTICLE_18801.HTM 关于《重构》 http://forum.eet-cn.com/BLOG_ARTICLE_18949.HTM 从实践理解设计 http://forum.eet-cn.com/BLOG_ARTICLE_18775.HTM  
相关资源
广告