By John Rezabek, Contributing Editor
To the dismay of some in the engineer/procure/construct (EPC) world, fieldbus can add complexity that was automated out of the point-to-point world decades ago. One's ability to execute a project "cookie-cutter" style, can be diminished noticeably.
Back in the day, a "conventional" job meant the instrument department could work on data sheets and bid tabs for weeks, while the piping designers determined where their process connections were going to be. Provided the client didn't make a gaggle of changes during detailed design, the flow of work from piping to instruments to I&E design was orderly and relatively free of uncertainty. The decisions and choices their client needed to make were also familiar and transmitted at well-known milestones during the effort. This orderly progression from concept to construction is a great comfort to contract consultants, and when you separate them from it, you don't get a lot of love.
How does fieldbus bring flux and uncertainty where there used to be order? Part of the equation—a big part—is that there are still relatively few firms with a critical mass of expertise in executing fieldbus jobs. On both the client and consultant side, inexperience and uncertainty breed ultra-conservatism. For example, there are recent threads on the Fieldbus Foundation end-user forums (http://forums.fieldbus.org) and LinkedIn groups about counting virtual communication relationships (VCRs). By and large, you have to go pretty crazy with your segment loading (greater than 16 devices or eight to 10 multi-input devices) before you even need to learn the acronym. If you must do it at all, just do it for the single worst case (most total I/O on a single segment) and call it a day. The section on VCRs was dropped from the latest revision of the AG-181 Systems Engineering Guide. Do yourself and your consultant a favor and fuhgeddaboudit.
Segment loading is another area where client fears and consultant inexperience can make both of them feel stuck in a bad romance. Early adopters—present company included—spent a lot of effort and ink worrying about ranking valves and loops, making sure they didn't have to exchange any packets with lower-caste devices. Then we found this to be largely a waste of time; the newest release of AG-181 says simply to shoot for 12 devices per segment, which leaves you a healthy 25% spare capacity for late changes and future additions. Final elements (e.g. valves) still need to be on the same segment with their associated process variable, but only a few are ever geographically diverse—more than a stone's throw away. Save the grey matter and highly compensated hours for these latter cases, as they will also be the ugly stepsisters of segment and spur length.
Examining segment and spur length can also burn scarce hours that aren't abundant when the electrical designers are finally able to start locating, filling and CADD-ing junction boxes. But this is another effort where only a handful of worst cases—segments with the most devices, the most distant from the host and the "geographically diverse"—really need to be examined rigorously before declaring the rest will work.
Segment loading also can have an impact on speed of response, so if your licensor insists on some phenomenal execution speeds, only obsess about it for those few where it makes a difference, and use "control in the field." The rest are likely to run happily with 1-sec macrocycles, the default speed for most legacy DCS controller loops. A cursory look at some segments with multiple control valves should suffice to see whether PID and AO execution times need to be specified for positioners.
Making some key choices early and sticking with your decisions can eliminate the late-term flux and rework dreaded by project managers and engineers. Next month's column will examine a few of the other key areas where a little early focus can pay dividends later in the game.