This checklist is for engineers and system integrators who are in the thick of developing a new machine or process line using Siemens TIA Portal. You've got your S7-1200 or S7-1500, you've mapped out the I/O, and you're starting to build the logic and the HMI screens. This isn't a tutorial on how to code a specific function. It's a practical, step-by-step guide—from a quality manager who has rejected plenty of first deliveries—on how to structure your development so it passes internal review, is maintainable, and doesn't cause headaches during commissioning. I review over 200 unique automation projects a year, and I've rejected about 18% of first submissions in 2024, mostly due to preventable issues with structure and documentation. This checklist covers the four steps I check every time.
This is the single biggest differentiator between projects I approve immediately and those I send back for rework. It's not about which style you use—it's that you use one consistently across the entire project.
I get projects where the same motor interlock is an input named 'M1_Start_PB' in one block and 'PB_Start_M1' in another. (That's an immediate rejection from me). Or where a tag is called 'Conveyor_Speed' in the PLC tags table but 'Conveyor_Speed_Ref' on the HMI screen. To be fair, neither is wrong individually. But the inconsistency multiplies the time it takes to debug or hand off. I was on a call with a system integrator last year where they spent three hours chasing a tag mismatch that could have been avoided with fifteen minutes of upfront planning.
Before you write a single line of code: define your naming rules. Something like:
Write it down, make it a project header, and enforce it. I've started using the TIA Portal tag table templates for this. The 30 minutes you spend setting this up will save you a ton of time later. It also makes handoff to a maintenance tech way easier. I can't tell you how many times the 'no modifications for 5 years' machine gets an upgrade, and the original naming scheme (or lack of one) becomes a nightmare.
The conventional wisdom is to write one big OB1 that calls everything. For a small, one-off machine, maybe that works. But for anything you might need to maintain, modify, or reuse, that approach fails instantly. What I've found in practice is that a modular structure with standardized interfaces for your function blocks (FBs) is way more important than using the most advanced TIA Portal features.
Here's the rule I enforce: every FB or FC that controls a physical device (motor, valve, conveyor) must have a standard interface. That interface includes:
This might sound like a lot of abstraction for something like a simple on/off pump. But when you have 80 pumps, 40 conveyors, and 30 valves to manage, having a consistent interface means you can use the same diagnostic screen for all of them. I had a project where the integrator used a different interface for every single device block. We had to write three separate HMI screens for motor diagnostics. That's a $22,000 redo and delayed our launch by three weeks.
A tip I picked up from a training workshop: use the UDT (User-Defined Type) for this interface definition. Create one UDT for the input structure, one for the output structure. This makes your block interface cleaner and forces consistency across all your FBs. If an engineer deviates from the UDT, it's immediately visible in the project tree.
This is the step that 90% of first-time developers overlook. They start by programming the PLC logic, then 'throw together' the HMI screens at the end. The result is an HMI that's a disorganized collection of screens, where navigation is inconsistent and alarms are slapped onto a generic screen. I've rejected projects because the emergency stop screen didn't have a fixed position in the navigation hierarchy. (That's a safety concern, not just a style preference.)
Before you map a single tag to an HMI element, do this:
The benefit is twofold. First, it's way faster to populate. You're just filling in the specific fields on the template. Second, it makes the system predictable for the operator. They always know where to find the 'Alarm' button (top right, always). They always know where the 'Home' button is (bottom left, always). This consistency reduces operator error. I ran a blind test with our maintenance team: same machine, one with a custom HMI layout, one with our standardized template. 72% identified the standardized one as 'more professional' without knowing the difference. The cost increase for the template approach was about $200 in development time. On a 50-screen project, that's trivial.
Most projects have alarms: 'Motor Overload', 'Low Pressure', 'Emergency Stop'. That's good (it's the minimum). But what separates a good project from a rejected one is the diagnostic information. An alarm says 'Motor 1 is in fault.' A diagnostic says 'Motor 1 is in fault because of a motor overload condition. The setpoint was 15 A and the feedback is 18 A. This is the 4th occurrence in the last hour.'
In TIA Portal, use the GetAlarm and GetAlarmState instructions, but also write logic that captures the context at the time of the alarm. Store the setpoint, the actual value, and a counter for the fault in the instance DB of your device block. Then display this in the alarm details screen (using your previously built template).
Here's the counter-intuitive part: I've seen teams spend two weeks perfecting the PID loop and zero time on this diagnostic data. On a $500,000 packaging line, a hard-to-diagnose 'output chute jam' alarm might cost five hours of downtime per month. A good diagnostic that says 'Output chute jam detected. Last 3 cycles were within spec. Motor 4 on the diverter shows a higher-than-normal current of 2.1A vs baseline 1.5A' can reduce that downtime to 30 minutes. That's $1,250 saved per month on that single alarm. The diagnostic logic took one engineer half a day to write. The payoff is way bigger than optimizing the PID loop by 0.5%. (Not that I don't optimize PID loops—they're also important—but this is the 'forgotten' step.)
A consequence I've seen: the machine builder who delivered the diagnostic-free system got a recall request for a software update at their cost. The engineering hours for that 'update' were three times the initial development cost. Don't be that vendor.
Before you finalize the project and export the runtime software, run through these checks:
Honestly, running through this checklist takes about two hours for a mid-sized project. Compare that to the potential cost of a failed commissioning, a callback for software updates, or a rejected payment because the client's engineer couldn't understand your code. I've rejected first deliveries for less. A well-structured, maintainable, and documented project is not a luxury—it's a contractual requirement with measurable benefits in uptime and lifecycle cost.