- South Australian Minsters Specification SA A2.2 Structural Engineering Software (2010)
- Australian Building Codes Board (ABCB) : Protocol for Structural Software version 2011.1
Both documents seem to impose a lot of paper shuffling nonsense into the exercise, and seriously miss the point and purpose of much of the software. The software will ultimately be used by customers the end-users of the structures, currently the software is used largely by sales people. To consider training and certifying the customer, the ultimate end-user of the structure being checked is silly. The whole point of the software is to be based on input parameters which are within the comprehension and interests of the end-user, and the outputs of the software are equally to match the end-users interests.
The software has to translate the end-users needs into technical requirements compliant with codes of practice behind the scenes. Code requirements and constraints are not something the end-user needs to deal with nor are they interested in.
The regulatory wants and whims have to be dealt with separately. It is not software that needs to be dealt with, it is repetitively manufactured structural products which need to be properly specified which needs to be dealt with. These structural products can be parametrically varied with in limitations, however I contend it is not acceptable for the specification to be buried within software simply because the software can deal with the variations. A written specification is still required and it will form the basis of the software.
It is really annoying when a manufacturer wants engineering input for a variation beyond the limits of their software, and they have no information what so ever about their product other than a black box computer program they push numbers through. It then becomes necessary to experiment with the black box to see if can gleam any idea of how it makes its assessment, and whether or not agree with it. At least when the suppliers held standard calculations, could look at the calc's and quickly conclude the assessment was inadequate or otherwise acceptable.
As one major problem with structural products is most consultants have no idea how the product can work. So they do calculations and conclude product not acceptable in the first place, so no way they can prove for the variation the manufacturer wants. One part of the problem is that standard products are based on testing, the other part of the problem however is that the original assessment by calculation is just plain incomplete. Now that incomplete assessment is getting hidden away and buried in proprietary software only available to manufacturers and their agents: not available to people who are responsible for granting regulatory approval to go ahead and build.
I don't however believe the solution to the problem involves generating large quantities of paperwork and signatures. The building industry just has not grasped QA versus QC. Quality cannot be inspected in, it has to be designed in. Similarly safety cannot be inspected in, it also has to be designed in. Design of the process doesn't involve creating a system which collects lots of signatures. Also a QA system accredited by a third party, is actually a QC system. If understand QA, then you do not have an accept or reject mentality, therefore getting accreditation or not by some supposed QA authority is contrary to QA philosophy.
Unfortunately the building regulator thought the idea was to get rid of inspections, and opened the door for non-compliance with approved documents. They have now put much of the inspection back, but they still missed the point. QC inspects at the end, and rejects the construction: and thus wastes time and materials. QA makes sure they get it right in the first place, and that requires an entirely different approach.
Quality considered in terms of signal to noise ratio (S/N), the building industry is still focused on boosting the signal rather than filtering out the noise. Hence lots of paperwork generated.
Training people to do the work, is somewhat Procrustean, as it takes the approach of make the person fit the job, rather than design the job to fit the people. The software is meant to be for untrained people, therefore it has to be designed accordingly. So training users, getting them certified, maintaining registers, and keeping certifications up to date, is just plain nonsense. As an interim measure whilst the software is not appropriately designed for the skills of the actual end-users, then training may be necessary. But it shouldn't be a requirement.
Also the requirement that the software be authored by a structural engineer is unacceptable. For certain a structural engineer needs to contribute to the software, but they have far inadequate training to design and develop appropriate user interfaces and error checking systems for software. The structural engineers are partly responsible for the software being rubbish and giving rise to the two controlling documents. The structural engineers may have got the structural calculations behind the scenes right, but the software itself is poor in terms of its user interface's: both the input and the output.
No one seems to be paying all that much attention to the point and purpose of calculations or engineering. Its all reduced to : will you sign off on this, will you provide a certificate. The fundamental basis of our system is adequate evidence-of-suitability, and a mere signature cannot be defended during a coroners inquest.
The two controlling documents provide a good starting point and guidance, but some of the requirements are highly obstructive are going to cause a lot of problems, and are unnecessary.
