Pressure Equipment in South Africa - SANS 347 Categories

Introduction of the Pressure Equipment Regulations and Conformity assessment in accordance with SANS 347:2010.

Under the Occupational Health and Safety act (Act 85 of 1993), the minister of Labour has introduced the Pressure Equipment Regulation (pdf) . This replaces the old Vessels Under Pressure Regulation.

The majority of the rules came into effect in April 2011.  There are a few key effects of the regulation.

Firstly, all vessels with a design pressure of over 50kPa are now covered by the act.  This often means that vessels previously excluded from the vessels under pressure regulations are now included.  For instance some atmospheric storage tanks are now included within the scope of these regulations.

Secondly the requirements for conformity assessment have been strengthened and more precisely defined.  These requirements are defined in SANS 347. 

The application of SANS 347 are based on Hazard categorisation.  This depends on the content of the vessel (Phase and level of hazard), the contained volume, and the design pressure.

Since adoption of these regulations, we have had many discussions with manufacturers and users where their understanding of these requirements is incomplete or based on the previous rules.  To help simplify this Bufo technology have launched a simple web tool.  You are welcome to use this tool to complete the classification and give you a summary of the requirements.

Remember that this tool can't replace somebody skilled in the use of the regulation.  It will however give you a quick confirmation of the main requirements that apply to your product.  Please feel free to comment on this as it is a work in progress and we will keep improving it based on your comments.

Link to the web tool.

Some Arbortext Tips

As we work on some projects that require automation I find that one of the things that keeps you busy is learning new terminology.  For example,  I have a automated report that ti want to put out in Arbortext for out Technical Publications Team.

It should be easy enough to do.  We populate an .xml file and then if we could just invoke Arbortext from the command line, we could set it up to compose and print or whatever else we need.   Searched the help without success.

To the web. Arbortext has an active community but they tend to focus on slightly more advanced topics.  No real sources of real beginner stuff.

Eventually I found the solution by accident.  The biggest problem was the names that I use.  Command line arguments? Command line options? Were not right - or ate least not used by the Arbortext community.  So Startup Commands and Options is the term.  Now that I found it it is very easy to do what I need to.

I guess that this will get easier as I get more involved.

Anyway,  this has given me some idea where some good Arbortext web resources are.

• Single Sourcing Solutions wiki (Subscription required)
• The Adapters Information Archive
• The Structured Authoring Blog, and
• PTC Community

Are some of my favorite.

By the way: that command that you can call from the command line to compose in batch mode:

"C:\Program Files (x86)\PTC\Arbortext Editor\bin\editor" -styler -C2 "$myparams['stylesheet']='stylesheetname.style'; $myparams['outputFile']='outfilename.pdf'; execute compose::compose_for_pdf(current_doc(),$myparams); exit" "filename.xml" 

 The key tricks are the use of single quotes and double quotes and using the execute call for the function.

Presenters at the NIASA localization Conference

I attended NIASA's Nuclear industry Localization Conference in Cape Town last Week.

First, I should point out that the conference was excellent, both in content and organization. Also that the strong interest and participation by South African industry is very encouraging.

I could not help but notice that there were more international speakers than South Africans.  So I built up the chart below:

Breakdown of Presenters by Nationality

Comments:

• less then half of the speakers were South African's (I count two of the speakers who have been resident for about 20 years as South Africans).
• The other nation with the most speakers was France.  A strong showing by EDF, Areva and some other french industry players.

NPP and reactor design

Sometimes it can help you to internalize what you know to try and write it down on one page. A  colleague asked me how you design a reactor, and how does this fit into the design of an Nuclear Power Plant. I guess I went a bit off topic but I thought that if I had to distill 10 years of doing this at PBMR and what I thought were the most important lessons. Especially if we do it over again at Bufo.

Design of a NPP happens at three levels, Plant design, System Design and Component Design.  You can add more levels but avoid unnecessary hierarchy.

Design of an NPP happens concurrently.  You need to find a balance between all-at-once and first-things-first. In reality things must happen in parallel. If you get key activities out of sequence, you are dead. (dead = rework, strong iterations and rework kills projects).  Working in the three levels helps you sequence better.  Plant ahead of system ahead of component.

You need to break the cycle of “Everybody waiting for inputs”.  The equation is:

Assumptions + margin = progress

How do you manage the project?  I think the best is a Stage-gate approach. All work in parallel.  Gat only reached when the last activity finished.

How to be most effective? Break the design work into suitable Life Cycle Phases.  This is consistent with a Front end loaded view of project management.  Normal split Pre-feasibility, feasibility / concept, Engineering, Construction, Commissioning and test.

Where is the boundary between these phases? There is no right answer, it is flexible and project specific.  Defining the boundary between phases must match the specific project goals/objectives. A yellow flag is when the boundary keeps being moved (typically in scope to stick to a date). 

When can you launch a DCD?  You can choose.  Remember though:  after the DCD you need to exercise change control, so not too early.  What detail do you need for a DCD?  You can choose.  Some are written as requirements documents, some written based on a full design.  Personally I would recommend a near complete Plant level design, supported by design of key systems.  Component design is probably unnecessary.

Change control?  How does it work in design.  The three levels are key.  Simplest rule we could find.  Specify higher level to lower.  A change at the lower level only needs to be controlled if it affects the document above it.  After DCD submission, its effect on the DCD needs to be considered as well.

What is design? It consists of 3 activities: (This is about the only thing that applies at all levels P/S/C)

1. Define the Inputs
2. Generate the Outputs (Lower level specs etc.) by: Defining the architecture, separating this (of the functionally) then specifying.
3. Document the Justification – link the inputs to the outputs.

What order is best to attack them in. 1.2.3.  Why?  Forwards development (1)-(2), backwards check. (2)-(3)-(1).

What are the main issues - Nuclear design (Mechanical).  Codes and Standards, which to use? Selecting loads and load classification.  This is sorted out at system design largely.

What are the key Red flags[1]:

• Strictly Hierarchical template. Same activities at P/S/C – you do different things at each level. One size fits all.
• Extreme idealization/abstraction
• Rigid rules
• Plans that are too Generic
• Fixation on: breakdowns (Product / system / facility / document …), processes, Baselines.  In fact any focus on process not product is counterproductive.  Especially at early stages

What makes a good designer?

• Ownership.  Own what you do.
• Invest yourself.  Then walk away.  You don’t always have the best idea, but if you don’t act like it you won’t prosper.

Specifically, is the design process broken into stages? 

•  Yes, in two dimensions P/S/C and life cycle.
• What inputs are required for each one of these stages with respect to design loads (vibration, seismic, transients, etc.) and how are they developed? 
•  For design loads: Plant – where to site, how it will be operated. System, what the system level loads are, how does the system response to plant operation, pressures etc. Component how does system response load the component.

How does the licensing and construction process fit in with these stages?

• Licensing:  As soon as you have the information you need.  What you license if fixed so no too early, licensing is risky and takes time so not too late.
• Construction,  you can only start when activity (2) lower level specs is complete a component level.  That is why you do justification after as well – to speed up the programme.

---

[1] Note that this document raises all of them.

Introduction: Building Bufo

Why a blog?  So 2000's.

Well, we are working on building a company (Bufo Technology), that operates in the Energy and Environment sectors in South Africa.

This blog is a place to post interesting observations and thoughts we encounter along the way. The opinions expressed in this blog are – more often then not- the opinions of the author of the post.  They are very rarely thought through. Generally inaccurate. Certainly boring.  Probably pointless.

Sometimes I think that it is only by explaining something that you can truly understand it yourself so here goes. Maybe it will be useful to you.