pcstru

They may have different safety features than typical indoor equipment and materials might be chosen which would not be suitable for an indoor environment - materials which might be severely toxic in a confined space in a fire for instance. There might be unexpectedly short specified operating lifetimes on components which are subject to the greater range of temperature cycling typically found in outdoor environments. The unit may have been removed from service having met or exceeded some safe operating lifetime limits. IMO there are (at least) two possible failures which could be worrying. A breakdown of the insulation in the transformer winding leads to 240V across the secondary or a short in the 12V side leads to overcurrent and a fire because of a lack of suitable fusing on the 12V side. I think I'd like to see opto isolators used in anything that interfaces mains to logic in a school environment (says someone who has been known to directly drive mains Triac chopper circuits from an Arduino at home!). Another possible failure is students subjecting the relays to too high a duty cycle (surely every student will want to try to get a relay to play the star wars theme). I'd worry about terminal blocks inside an enclosure which students might access. Aren't fully insulated crimped connectors now standard for any mains electrical work? Cat 5 seems to be rated under 1A per strand and for power handling (0.6A Cat5e) and in short runs might be prone to getting hot (resistance seems to be quite high per meter). I'd expect traffic lights - even high efficiency LED ones to draw more than 12W per 'bulb'. What current have you actually measured to the bulb? I think all I'd be able to say to students is "do not under any circumstances try this at home!" - at which point I'd wonder why I am setting such an example. One worry might be students going away and using relays to switch inductive mains loads - a distinction which might be difficult for secondary students but which could be quite dangerous. IMO it would be better to just say "don't do this" and then show them how to do stuff working with relatively safe battery driven or 12v circuits driven by lab bench power supplies. Is accessing lights something they would be allowed to do? If a student is in the room alone, can they access the back panel without a key? As I say, I do think it is the kind of thing that can impress and inspire students and is probably pretty safe but there are numerous potential pitfalls for the unwary and much safer alternatives. Sorry to appear to be such a killjoy!

It sounds like a project that could impress and inspire students, which is great. I still have some concerns that it is problematic. 1. The components are not designed for the application. Did the designers of the lights envisage (for instance) that the system would even be used indoors? If not, they may have made design choices about materials and failure modes that could be problematic. 2. The components might rely on system elements elsewhere (i.e. not present in the bits you have) for their ultimate safety. 3. The description could indicate the 12V lines are wired to the secondary winding on a transformer (post rectification if DC), which if there is a problem could expose those 12v lines to the mains or a current overload. Is such a design compliant with IET regulations in this application? 4. Work on mains in a school should be undertaken by a competent individual with appropriate training and expertise. Are you a qualified electrician or electrical engineer? If not, at the very least your schools public liability insurance might not cover any accident (a fire as a result of those 12v lines shorting and exceeding their rated current for example), while if someone got injured you may face much worse. 5. You seem to have set it up in a computer room. Is the supply fitted with an appropriate RCD - as should be the case in a science lab but may not be the case elsewhere? 6. Are you entirely comfortable setting an example to pupils of hacking mains powered articles and driving them from a Raspberry Pi. Are you adequately covering the dangers of doing that and if so, how come you are still doing it?! 7. Did you get a senior member of staff to sign off the risk assessment? If not, who did? On the last, when I think about doing a risk assessment for this kind of thing, the big problem is that it is easy to mitigate any risk arising from use of mains components by substituting readily available 12V components while still demonstrating exactly the same principles of electronic control. Want bright coloured lights? Use high powered LED's driven from a 12V buck driver. Sorry if that sounds like H&S gone mad. I'd guess there is an extremely small chance that this could go wrong - it's just if it does, it could land someone (you or anyone else inspired to do this) in the deep stuff.

Nice work. I hope I don't cause offence but personally, I'd be very wary of interfacing to mains anything via relay boards in a school project.

Most bikes on average probably cost a significant amount more than a cheap-o car to maintain per mile, in part because they, on average, do relatively few miles. Another factor to think about is while you might skimp on maintenance on a car, doing so on a bike is madness. Motorways are safer than A or B roads (one of the big problems with A/B roads is having an accident and not being found/attended by an ambulance quickly). That's somewhat worse on a bike because a common accident is people failing to make a corner (no one else involved). The most common accident (45% in 2014) is someone not seeing you and pulling out in front of you. In terms of risk vs driving a car, 19% of all road fatalities in GB involved motorcycle users, yet they account for only 1% of all traffic. You can of course manage the risk with good roadcraft and training (you can never entirely eliminate it but advanced training has significant impact in risk reduction as evidenced by insurance discounts they can unlock). Good luck, enjoy it and stay safe.

What about the older 660cc single cylinder MT03? Can be had quite cheaply, are unusual and good fun without being too much of a risk to your licence.

If it does then they should find it easy to provide the functionality for local installs (probably at some fairly significant cost) or perhaps if schools think it is actually a requirement, then they need to move to a hosted service.

I think you are just repeating claims that I have tried to address by considering the actual detail of them, but this time you feel the need to mix in a little ad hominem. So you are right the 'argument' has become circular and other than a response to anyone that wants to take up the bet, I guess it's back to lurk mode for me.

It was built in from the beginning? The phrase "their data" doesn't quite describe what you think it does (i.e. you can see who is accessing data but not with any granularity)? It could be any number of things.

Evidence in a criminal case would need to be beyond reasonable doubt. I struggle to see how a log could be that evidence when someone could lean over and view data on a screen or printout. If you are talking about mere disciplinary and you have the luxury of gathering such evidence, then there are other, probably better ways to do it but it is not safeguarding if you are gathering evidence to prove suspicions you already have. Oh come on. Print release simply means it is not left lying around on the printer - usually (print release doesn't stop someone starting a print and wandering off) nor does it control what happens to the paper after printing. It is interesting that here you are OK with policy, procedure and trust keeping the information secure, but in the context of an application, you think that those are deficient. I'm not. I'm arguing that the enormous cost is not justified because the problem can be and already is better addressed by other means. I'm probably about done with it but I'll happily take a bet with anyone that no company providing schools MIS systems will commit to offer "read logging" (a method of recording access to data by application users) in the next 2 years. Anyone who believes that this is a statutory requirement mandated by safeguarding should consider that a safe bet and take my money. I don't expect any takers.

I don't see how you can run a software development business like a schools MIS system without some some kind of rational "business case" driving the development of features. That would seem to be an argument that says "make software that no one wants". There is a business case for having user CRs but each CR then needs to be considered in terms of it's cost and the benefit. If there is a huge cost but no real benefit then why would customers pay for it? If this is a genuine "statutory" need then it should be a feature of all MIS suppliers. Read logging certainly isn't. Even auditing changes in a way that is application aware isn't covered well by the big players and I doubt it is a factor in many purchasing or renewal decisions (it wasn't in ours which was just ~2 years back). Still, if people here are right - all MIS suppliers will need to do this or we will not be able to buy their products. If it is a serious safeguarding issue then that is surely what it will come down to in the end?

This falls into the categories I posted here. If they should have access, i.e. they are legitimately employed to do a job and need to be granted access to the data via permissions, then what will a log tell you about that access? How can you tell if their access was legitimate or not? If the 'hint' (whatever that might be) is sufficient to cause suspicion which is a safeguarding issue (i.e. you believe the member of staff represents a threat to the child) then access should surely be removed entirely as should the member of staff? You don't wait to see if the risk turns into an issue just so you have some evidence. The fact that you acknowledge that there is a way to drive a coach and horses through what would be a massive piece of development tells me it is utterly useless. You trust people not to access the database directly yet you think they are stupid enough to know they can have that access but yet they do it through the software that they know is monitoring them when they are (knowingly!) up to no good? If a company suggested that this was effective as a security measure they would be rightly laughed out of the forum (witness the criticism (rightly) of Impero). If you don't trust your technical staff then you are going to need to act in a way that entirely bypasses them if you are into gathering evidence. If you are gathering evidence, there are other, probably better ways to do it but ... There is a disconnect also between gathering evidence when you have a reasonable suspicion that staff are a safeguarding issue - i.e. you suspect they are an actual risk to children's safety. If the suspicion is reasonable, you remove them, you do not leave children vulnerable to them while you gather more evidence (more because you must already have some). That would effectively be using the students as bait. Let's also look at some other aspects. How does the school deal with access to printed reports or someone looking over a shoulder at someone else's screen? If you build in, at huge expense, read logging to the application & database, how do you cover those cases? I appreciate that not being able to solve all the issues might not be a reason not to solve any of them, but when you look at the actual problems here, there are other solutions that are equally or more effective given the possible circumstances that can arise. Putting trust in a half baked technical solution would just be ... half baked.

I can't recall anyone seriously asking for read/view logging in an MIS product before and I've yet to see here a real justification for it - but I invite anyone to offer examples (see my post here) where the feature would not be covered by effective alternatives. I do recall people asking for access rights which were sensitive to some data context (i.e you could have rights to view some records in a table but not others), IMO that was equally silly given the expense of both the development and operation of the product and not doing it was a good call. Sometimes it is necessary to save customers from themselves and not give them what they think they want. In terms of logging changes (audit of writes), I think that is probably more important since writes affect data integrity but I'm not clear that it is a kind of "statutory must have" necessitated by policy or legislation around safeguarding. It might benefit the suppliers since it would potentially make it easy to spot hacked DB changes (users hacking the data via the back end or unauthorised 3rd party tools). But it is the kind of feature that if it is not in the architecture/framework, it is very difficult (expensive) to build into a mature product after the fact. From Capita's POV it must be hard to see it as vital since no other product does a good job of it (as far as I know), if it does it at all. It wasn't something that featured on our list of "must have" requirements when we were looking for a product. Perhaps we missed a trick but I don't currently think so. In terms of managing development requests; development is generally resource and time constrained - so you always have a situation where there is more demand on development than can be met for a particular release and many releases are constrained by the timing of statutory requirements so you have limited flexibility on the time available. The availability of development resource has to be split between customer requests and internal development needs (bug fixing and enhancements identified by product managers). The changes being discussed here have the potential to displace all other customer requests for a release cycle (or more than one) as well as internal development requests. Given that, then the popularity of a CR simply can't be decoupled from the cost of it - that would be a very poor way to manage software development. Perhaps MIS suppliers do miss a trick when tracking user CRs, they should publish a cost factor so that users can see requests ranked according to votes and the cost of actually doing them. There could then be an appreciation that in the next release(s) you can have either these 100 popular CR's, or this single equally popular request. Which do you think they should do in that case, the 100 or the 1? Should a CR simply be evaluated on popularity without any reference to the cost? So, yes, perhaps I am missing the point, but if I am, I'm not sure what it is. I'm happy to be educated though so have at it!

I'm presuming you are talking about tracking changes rather than logging what users are doing and trying to infer from that what they are accessing? For change tracking iut seems like a possible approach but how do you track SIMS users at the database level with something that is not application aware when the users are part of the application (i.e. they are just more data in a table)? Part of the problem here would be avoiding false positives - this is potentially evidence that would be used in a disciplinary or follow on employment tribunal or even a criminal case, so it would need to be rock solid. Just assuring that would be a difficult task and any changes SIMS make from one release to the next could break it badly.

My apologies if I have offended you. You make a claim that something is a "bit of work but not a huge amount". To me that looks like a figure you have plucked out of thin air. I have some experience (13 years) of exactly the kind of software development involved and my experience tells me you are very wrong. It is potentially a large amount of work - certainly many hundreds of man days would be required over the entire suite to build use logging into the client elements. They would need to be there otherwise it is impossible to distinguish database activity that is significant (presenting information to users) rather than being used to (say) enforce constraints or perform data validation.

Would you like to quantify that additional work that is not a "huge amount"? Perhaps avoid the complexity of releasing a coherent 'platform' and just try to get some ballpark figures for the work to the 'forms' by the principle disciplines - the analysts, developers and testers? When you have that, how does the demand stack up against the cost? Your assumptions remind me of the kind of stuff sales people would come back with from customers when I was in that kind of game. Say what? By when? You are ****ing kidding! On the other hand, they got the whacky bonuses - not us grunts who just had to deliver ... something!

@Geoff, applause for that. I certainly did learn something but there is a rather limited context where you can pull off that trick. It's not a prospect for the schema of a production system! ... unless I'm missing something really quite big. But it is late and Friday - so I might well be!

I'm curious as to the actual use of some kind of access log, apologies if someone has covered it. In terms of safeguarding : 1. It might flag someone as accessing something they shouldn't. Solution - use the security rights mechanisms provided to prevent such access. Operate good policy and procedure so that access rights are allocated appropriately when staff take on particular roles. There are already a variety of ways of assuring the quality of the implementation of that policy and procedure, which is effectively the use case here. 2. You already suspect an individual is accessing information that they should not be but, they either need access to that information for quite legitimate purposes or granularity of rights in the application means effectively that. Solution - this is into disciplinary territory and if you need to monitor what the individual is doing to obtain proof, there are very cheap and effective ways to do that from cameras to screen recording to capturing all their network traffic. Any others?

Really? I would be kind of gob smacked if it were ever to be a trigger event for a user defined stored procedure on a table in any implementation of a SQL database. In the context of an n-tier architecture, a SIMS customer using SQL profiling (which is aimed at DBA's doing database optimisation) to track SELECTS would be useless. There is no way to distinguish between selects that result in information being presented to the user and selects which are run as a result of enforcing constraints or data aggregation. It would however be a very effective way to cripple your database performance if every single select results in a database write to audit it. SUSER_NAME() as I said returns the security context. If you log in using windows credentials, then you will get what you say because that is the security context, but many if not most application software effectively uses a single database user and logs in as that while managing the actual application users themselves. That is true for SIMS, CMIS and Bromcom as far as I am aware.

We used to clear down the table regularly and retain the deleted records but as I said, the times when we actually wanted to know "who did _that_?", the actual information being audited was useless. Perhaps we were just unlucky (or you have been lucky!).

Can you? There is a clause to create a trigger on select? Where? I must be misunderstanding that too then. SUSER_NAME() will return the user in the current security context, which should be the DB Login (for SIMS). That seems to be how it works here so I'd be delighted to hear what I'm doing wrong.

Not sure I understand that. You are saying you used their audit trail and just truncated it to the last months records? Our experience was that the information was simply not recorded by the audit - it wasn't a problem with the number of records, the information just wasn't there (or if it was, Serco didn't understand how to make any sense of it). I did think of doing something similar to @Geoff's suggestion, but CMIS/ePortal take the same approach as SIMS - the actual application end user is not the DB user and it would have been a lot of effort to close that gap. [ETA - there is also a significant risk that a blunt table trigger approach to audit will play cripple Mr Database at some point (most likely when you least expect it or need it)]

Our experience with CMIS/ePortal was that any time we wanted to know who had made a change, the supposed audit trail was not of any use. So it was a bit of a chocolate teapot for us.

That may work if you want to know that a change was made by the DB user that everyone uses to make a connection to the SIMS DB. Actual SIMS users are handled by the application, not the database. Also, the request here as I understand it is for logging access, not changes.

Unless you can re-write the history of SIMS .net development and build it in from the start, then it would be complex and expensive to engineer it into a mature, stable product. Apart from anything else, it would involve a massive QA effort since it has to affect every single access to every single bit of data via every single means. If you can do it as easily as you think you can, then do it as a 3rd party product and you will, according to then demand here, be mining a rich vein of pure gold. Technically, I can see how you might put something in the middle as a proxy that would potentially capture the data you would need, the complex part then would be making sense of it and presenting it in a usable, digestible, robust enough to use in a disciplinary context, form. If you can actually do that, @PhilNeal would probably want to arrange for you a very well paid job, although he might find himself in a bidding war with every other MIS (or any other large scare specialist corporate information system) supplier out there.

I'm not a big fan of the huge corporate beast that is Capita, but such statements are disingenuous to the many people that work hard to try to make SIMS a good product and offer a good quality service. Capita's profit margins is not what actually motivates them day in day out.