Alright, welcome back to A Glimpse of Engineering. I'm Caleb Thompson, and as always, I'm joined by Emily Cartwright. Emily, how's things up north?Hey Caleb! Not too bad, mate. Bit of rain, bit of mud, but that's Pilbara life. Excited to dig into today's topic—foundations of engineering design at OFI. This is the stuff that keeps us out of trouble, right?Absolutely. And, you know, after last episode's deep dive into batteries, it's kind of nice to get back to the nuts and bolts of how projects actually get delivered. So, let's start with the big picture—why do we even bother with all these structured procedures in engineering?Yeah, it's not just paperwork for the sake of it. Structured procedures are what keep the wheels turning smoothly. At OFI, the whole process is about making sure we deliver compliant, high-quality low voltage switchgear and controlgear assemblies. But it's also about engineering controls—making sure every stage, from design to handover, is checked and double-checked.Right, and it's not just about ticking boxes. It's about lifecycle management. So, you've got design, construction, verification, and then the final handover. Each stage has its own checks and balances. I mean, you can't just design something and hope for the best, can you?No way. If you skip a step, you end up with rework, or worse—something unsafe. The process is there to protect everyone: the client, the team, and the end users. Plus, it gives us a way to capture lessons learned, so we don't repeat mistakes. It's a bit like what we talked about in episode one—those 214 injury-free days didn't happen by accident. It's all about process and vigilance.Yeah, and I think people sometimes underestimate how much rigor goes into even the smallest project. It's not just about building something that works, it's about building something that lasts, that's safe, and that meets every requirement along the way.And speaking of requirements, let's talk compliance. This is the bit that gets a lot of new grads sweating, but it's non-negotiable. In WA, we're bound by the Electricity Act of 1945 and the Electricity Licensing Regulations from 1991. Those aren't just guidelines—they're law.Yeah, and those laws call in the AS/NZS 3000 standard, right? The wiring rules. I always get a bit lost in the numbers, but that's the backbone for electrical installations across Australia.Exactly. And it's not just AS/NZS 3000. That standard can call up a whole bunch of other standards, depending on the project. But the key thing is, if you don't comply, the consequences are real. We're talking fines, jail time in extreme cases, and—honestly—project risks that can sink a business.Yeah, it's not just a slap on the wrist. And, you know, we've seen in previous episodes how standards and compliance are the backbone of safety. Like, in episode three, we talked about how standards like ASNZS 60079 keep hazardous sites safe. It's the same logic here—compliance isn't just a box to tick, it's a shield for everyone involved.Totally. And at OFI, we've got a bunch of safeguards—peer reviews, checklists, SME sign-offs—but at the end of the day, it's every engineer's responsibility to keep their knowledge up to date and check their own work. You can't just rely on someone else to catch your mistakes.Yeah, and I think that's a good point. The process is there to help, but it's not a substitute for personal accountability. If you cut corners, you're not just risking your own neck, you're risking the whole team's reputation—and sometimes, people's lives.So, let's get into the weeds a bit—codes and standards. There's a whole alphabet soup of them, and I always wonder, how do you know which ones actually apply to your project?Yeah, it's a bit of a minefield. The main thing is to start with the basics—AS/NZS 3000 for wiring, AS/NZS 61439 for low voltage switchgear and controlgear assemblies, and then you branch out depending on the job. Like, if you're working on a mine site, you might need AS/NZS 3007 or 4871. If it's a fire system, AS 1670. There's a standard for pretty much everything.And then there's the difference between what's normative and what's informative, right? I always get those mixed up. Is it 'shall' means you have to do it, and 'should' is more like a recommendation?Spot on. 'Shall' is mandatory—if the standard says you shall do something, you have to do it. 'Should' is more like, it's good practice, but you might have a valid reason not to. But honestly, if you ignore a 'should', you better have a solid justification and document it. Otherwise, you're just asking for trouble in an audit or if something goes wrong.Yeah, and I guess that's where experience comes in—knowing when you can deviate and when you absolutely can't. And, like, having those internal checklists and templates helps keep everyone on the same page.Exactly. And don't be afraid to ask. If you're not sure which standards apply, talk to your lead engineer or the project manager. It's better to ask a dumb question than make a dumb mistake.Alright, let's switch gears a bit—pun intended—and talk about some of the terms that come up all the time, especially from AS/NZS 61439. I always hear 'assembly', 'busbar', 'functional unit', and so on, but what do they actually mean in practice?Yeah, these terms get thrown around a lot. So, 'assembly' is basically the whole system—the enclosure, busbars, all the components, as defined by the original manufacturer. It's like the full kit you put together to make a switchboard.And busbars—those are the big copper or aluminium bars that carry current through the assembly, right?Exactly. The main busbar is the backbone, and then you might have distribution busbars branching off to feed different sections. Then you've got 'functional units', which are all the bits that work together to do a specific job—like a motor starter or a protection relay. Each functional unit is its own little ecosystem inside the bigger assembly.So, in a real project, how do these definitions actually play out?Alright, so say we're building a motor control centre for a mine site. The assembly is the whole MCC—the enclosure, busbars, all the gear inside. The main busbar runs along the back, and each motor starter is a functional unit. If we need to add a new pump, we add a new functional unit to the assembly, connect it to the busbar, and make sure it all complies with AS/NZS 61439. It's all about making sure every part is defined, tested, and documented, so nothing gets missed.Makes sense. And I guess having those clear definitions helps when you're talking to clients or other engineers—everyone knows exactly what you're referring to.Yeah, and it keeps the documentation clean. If you start mixing up terms, that's when things get messy and mistakes happen.Alright, last bit for today—abbreviations and reference tools. There's a lot of jargon in this field. I mean, I still get tripped up by things like BOM, MCC, MEN, RTU, DLP. Can you run through a few of those?Sure thing. BOM is Bill of Materials—that's your shopping list for the assembly. MCC is Motor Control Centre, basically a big switchboard that controls motors. MEN stands for Multiple Earthed Neutral, which is a type of earthing system. RTU is Remote Terminal Unit, used for remote monitoring and control. DLP is Defects and Liability Period—the time after handover when the contractor is still responsible for fixing any issues.And then there are all the internal OFI documents and templates. I know there's a design change notification form, engineering checklists, product and cable repositories. How do those actually help in the process?Honestly, they're lifesavers. The design change notification form keeps everyone in the loop when something changes. The engineering checklist makes sure nothing gets missed at any stage. The product and cable repositories mean you don't have to reinvent the wheel every time—you can see what's been used before, grab datasheets, and keep things consistent. And with tools like Fusion 360 linked to the product repository, the workshop team can see 3D models and general arrangement drawings in real time. It just makes everything smoother.Yeah, it's a lot to take in, but it all comes back to that idea of process and rigor. You can't just wing it and hope for the best.Exactly. And that's what sets apart a good engineering team from a great one—attention to detail, using the right tools, and never cutting corners.Well, that's a wrap for today. Next time, we're going to dig deeper into the design phase itself—how requirements get turned into real-world solutions. Emily, always a pleasure.Thanks Caleb. Looking forward to it. And thanks to everyone for tuning in—catch you next time on A Glimpse of Engineering.See ya, folks!

Episodes

Foundations of Engineering Design at OFI