第一招：人
中国有句古话，做一件事需要天时地利人和，其实，搞砸一件事也是如此。天时地利属于客观条件，今天要教大家的是即使客观条件有利于功能安全，我们也要靠主观彻底破坏彻底搞砸的方法。我命由我不由天，所以我们先主要讨论下“人”的问题。
如果一个功能安全项目中每一个角色都有很强的责任心和使命感，认真踏实，遵规守纪，技术优秀，能力称职，那么搞砸这个产品的功能安全难度太大了，但是不要灰心，只要你认真挖掘，有些项目中总会有那么几个能够助攻你完成破坏大业的人，如果这样的人又是处在比较重要的角色上，例如处在决策者、总工/总师、系统设计、硬件开发、软件开发、功能安全、测试、验证和确认等重要位置，那么你的机会就来了。再如果这样的人在项目中又掌握一定的权力，那么恭喜你，搞砸一个产品功能安全的目标触手可及了。以下特征有助于帮你识别这样的助攻人才：
急功近利。心里只想着利益，奉行天下万事唯快不破，而不遵循功能安全产品开发的客观规律；
投机取巧，敷衍了事。做事不求甚解，成果东拼西凑，只做表面功夫，说起来头头是道，实则背后挖了一堆坑；
不懂装懂。知其然不知其所以然，了解点皮毛就敢飞上天，实际能力配不上说过的大话，把产品功能安全带到一条不那么正确的路上；
推卸责任。做事没有担当，自己铺展的烂摊子总要想方设法怨到别人头上，不会反思自我，不会进取改进，责任都推出去了，就和自己没有关系了，所以不求做好，只求自保；
自私狭隘，争抢风头。做事不是以把事情本身做好为目标，而是攀比与争抢，诋毁别人的有益成果，总有那么一股怨念驱使着自卑而变得咄咄逼人；
对功能安全缺少敬畏之心。从心底里就完全不懂功能安全也不在乎是否安全，或者虽然懂功能安全是什么，但同样漠视安全带来的后果。
以上这些特质的人，遇到了就收下吧，哪怕只有一两个，他们也一定会帮你把产品功能安全搞砸的。
第二招：需求
在功能安全项目中，需求的管理与跟踪至关重要，所以想要搞砸功能安全，你先搞砸需求那么就成功了一半。首先，需求来源于用户，项目启动后，需要把用户需求转化为系统需求，作为项目设计开发、验证测试的原始依据，因此需求错，将会导致步步错。
想要搞砸功能安全，制定需求时只需要以下几步：
需求制定随意化。不用费时费力把外部的客户需求研究透彻，只需要拍脑袋定需求即可，反正在项目中，系统需求就是源头，你定什么后面就做什么。
需求描述歧义化。你要发挥障眼法，把需求描述的模棱两可，以“一千个人眼中有一千个哈姆雷特”为目标，要让一千个人对同一条需求能够产生一千种解读。
需求模糊化。针对一些有具体特定要求、定量要求的需求，你只需含含糊糊的描述，让其他人无法明确理解意图，无从验证。
需求不跟踪，不落实。清晰的条目化需求有助于需求的跟踪与正确实现，每条需求带有唯一编号进行设计跟踪和测试验证，都是保证需求落实的手段，所以你一定不要把需求条目弄得太清晰，至于安全认证流程中要求的需求跟踪，编号胡乱对应一下，内容不用认真分析是否完全一致对应。
需求不完整。制定需求时考虑不周，需求不完整，足可以给后面的开发工作带来一系列的麻烦，到具体的细节时不知道该如何处理，如果开发人员也是你的搞砸团队队友，那么就可以随意发挥，这样产品的后果就会存在无限种可能了。
总之，要想搞砸一个产品的功能安全，只需要在制定需求时漫不经心一点，就足够让后面的工作抓狂了，一份以“搞砸”为目标的系统需求是万恶之源，把它应用于项目中就相当于打开了潘多拉魔盒，邪恶就会由此释放。
第三招：设计与开发
设计开发作为研发产品的核心环节，想要搞砸产品的功能安全，在设计开发上搞事情是可以事半功倍的，在设计细节上偷偷埋个雷再遇上一群“搞砸”队友，很多时候都会无人知晓。
首先是系统层面的设计，一个好的功能安全项目，这个阶段需要统筹全局，从系统角度出发，基于系统需求制定系统架构及策略，确保系统实现功能正确，性能良好。反之，你在进行系统设计时，只要脑子空空，不统筹，不思考，东拼西凑做出的系统设计，多半都离搞砸不远了。你无需考虑功能分配的是否合理，系统层面的安全策略是否足够，也无需顾忌系统故障检测方法与覆盖，更不需要关注系统导向安全的时间性能，反正是冲着搞砸的方向努力的，只需要胡乱搞出一份系统设计交差即可，即使以后出现问题，你还可以任性的甩包给软件，硬件，安全专业。
对于硬件设计的“搞砸队”队友，你只需生搬硬套个硬件电路，不需要深入思考他的失效模式与影响。对于器件选型，你也可以完全放飞自我，什么降额设计，电气隔离，EMC防护，通通可以不用那么用心设计，对于逻辑电与接口电，也可以混淆不区分，对于安全机制与策略，也可以佛系选择，如果嫌弃动态的检测有点麻烦，那就直接都选择静态好了，反正功能实现了，至于安不安全那就不关心了。
对于软件开发，很多人都说了靠流程去保证软件的质量，那么就更加可以忽略设计细节了。管它什么防御性编程，管它什么内存保护，管它软件逻辑是否完美，管它具体实现与需求细节分支是否完全一致，总之，在不深究的情况下，功能实现了即可，至于在特定场景下，软件是否会产生一些意想不到的情况，是否在故障时真正导向安全，这些都不是一个搞砸人的目标。最多你按标准的流程、技术方法来敷衍执行，原则上可能也没发现你的差错，但背后你绝对有实力挖出一堆坑，最终成为搞砸产品功能安全的刽子手。
第四招：功能安全
目前功能安全的门槛参差不齐，人员水平鱼龙混杂，看了几遍标准完全没有实战经验就可以大谈特谈功能安全了，所以你从这方面来搞砸产品的功能安全是可以让人毫无防备的。
安全分析可深入也可肤浅，你非要这样分析，没有人能够制止你，所以你根本无需自己埋雷，你只需水平不足够看到别人的雷即可。你可以自己根本没有做过一个完整的功能安全项目就夸夸其谈，你也可以不懂硬件、不懂软件就瞎指挥，你还可以认为就按照标准要求完成相关的交付物你就实现了功能安全，你更可以搬弄些标准术语让自己显得深有建树，总之，你可以走你的路，没有人能够阻止你搞砸的脚步。
什么HAZOP，什么FMEA，什么HARA，什么FTA，什么DFA，什么PHA，什么SHA，什么IHA，什么OSHA…….你都可以照葫芦画瓢。你也可以不用那么关心安全策略是否合理，安全机制是否足够，安全防护是否实现，软硬件开发细节是否满足功能安全要求，分析的场景是否全面，测试对安全防护的检测是否充分，你可以站在很高的高度去分析，高到不去了解实现细节。
第五招：测试、验证与确认
对于一个功能安全产品的开发项目，测试、验证和确认是一道道壁垒和最后的防线，如果你在这个时候选择对别人埋的雷视而不见，或者根本不去排查雷区，慷慨放行，那么产品的功能安全就可以彻底搞砸了，你虽然不是搞砸的始作俑者，但你绝对是重要的助推者。
单元测试你完全可以冠冕堂皇的测试语句覆盖率、分支覆盖率和MCDC覆盖率，不用管具体的设计意图的，函数本身设计意图错就错了嘛。集成测试和确认测试你只需要做做表面功夫，正向的功能都测试了即可，不用管什么故障插入测试，绞尽脑汁穷举各种故障场景失效情况进行测试费时又费力，如果强行要求，只挑选二三蒙混过关就行了。对于测试用例的设计，测试结果的要求也不用那么较真，一切看心情；对于接口测试，调用关系和接口协议的测试随便测一测，不用遍历细节。
至于文档验证，那就更容易了，你可以对着检查单都写通过，而不深究每一个文档内容是否真正正确，真正满足要求。你也可以出工不出力，每个文档都浏览但只是走马观花完全查不出问题，总之，天下套路千千万，相信你都懂的。
第六招：安全认证
如果你认为产品的安全认证可以保障你没办法搞砸功能安全，那你就大错特错了。尽管安全认证都是有资质的第三方独立机构，但是还有以下漏洞你可以钻：
安全认证公司风格不一，人员水平差别较大，难免也会存在想和你一起搞砸功能安全的同伙；
鉴于技术保密性，安全认证过程中第三方评估人员未必能够获取你全部的资料而面面俱到，所以你搞砸的小动作可以在第三方评估监管下神不知鬼不觉的进行；
安全认证是建立在双方相互信任的基础上，如果你提交呈现的是一份造假的数据或文件，第三方评估人员也无从知晓。
因此，安全认证也无法阻挡你搞砸一个产品功能安全的行动，只要你有这种搞砸意识，那么有志者事竟成。
第七招：逃
等你彻底搞砸一个产品的功能安全后，并不是高枕无忧了，后面隐藏着无限风险，因此教你最后一招：逃！温馨提示以下几点：
产品上线后，你要随时做好跑路的准备，一旦发生功能安全事故，你可能被追责，因此三十六计走为上计，但这个走也是有技术含量的，不会因为你换了公司换了职位就可以免责，至于走到哪里去，还需要你自己琢磨。
如果你搞砸的是一个轨道交通相关产品，那么今后你和你的家人、朋友要尽量避免乘坐了，说不定什么时候你埋下的雷就会炸了，那可是要命的事情，所以乘坐相关轨道交通出行需慎重。
如果你搞砸的是汽车电子相关产品，那么首先记得不要买相关的品牌汽车与产品，另外，在路上走路行车都要万分小心了，你不撞它不代表它不撞你，你的雷最终炸了你自己就不好了。
以上内容如果你觉得只是危言耸听，事故只是小概率事件，那么请记住世间存在因果报应的可能，不是不报，时候未到。