"Software As A Service" business in Canada 2

[AngieMa]

Hi Folks:

I have mechanical engineering background in upstream oil and gas and have developed a software for engineering calculations. The software domain of application relates to reservoir engineering. My goal is to monetize the software and do consulting activity around it. Being myself located in Canada, I am not in position to work as consultant until I get the appropriate professional registrations with the provincial regulator. While this process is ongoing, I understand that any business activity which can be viewed as practicing engineering and advising/consulting clients - on this instance ion matters interesting reservoir engineering - would simply be NOT allowed in absence of the relevant permits.

WHILE THE CLEARING OF THE NECESSARY PERMITS IS IN PROGRESS, I would like to sell straight away software licenses to users in order to cover some running costs. More specifically, the idea is to start billing clients on the basis of software related service such as:

a- Maintenance of the software, operation on database systems
b- Compensation for running costs related to use of hosting services, processing power, etc.
c- Other software support services (license management, etc.)
...

One troubling area relates to the fact that the software generates engineering outputs (parameters, etc.) which themselves are intended for consulting and for software-aided decisions. The audience is typically reservoir/petroleum engineers, etc.

My question : Can I run a business a concept solely based on software services as itemized above keeping any reservoir engineering matters out of the scope. So, clients would be billed on this basis and disclaimer shall be agreed that any business activity / service offered to client must not be regarded as advising them.

Would this be doable and a safe option?

 

[EnergyProfessional]

No lawyer here. but as long as your client enters and reviews all the data, you are just a software vendor.
The software I use in my field has enough disclaimers to keep all liability on my side. Obviously you should make the EULA legal-tight. Also when I send a file to our software support, they never make an adjustment, they just tell me what I could adjust.

If you actually enter values for their specific situation, you are designing and take more responsibility. You should clearly separate software sale, and design.

If selling a software requires a specific license, I don't know. Some software requires some certification. For example DoE certifies certain energy simulations to be used for tax credits or other legal reasons.

 

[IRstuff]

In the US, the EOR has final responsibility for any calculations.

I don't see the software, and by inference, the programmer, as doing "engineering" as proscribed by licensure laws; it's no different than a calculator, or Excel, for that matter. They're all tools used by the EOR to do calculations. Now, the EOR might try to sue you for damages, but that's usually averted by the software end-user license, which typically has a "caveat emptor" clause, among others that basically says the programmer makes no warranty with respect to the accuracy, suitability, and applicability of the software to any application, even though the advertising might imply otherwise.

TTFN (ta ta for now)
I can do absolutely anything. I'm an expert!

https://www.youtube.com/watch?v=BKorP55Aqvg

faq731-376 forum1529 Entire Forum list

http://www.eng-tips.com/forumlist.cfm

 

[jmec87]

I recommend checking the rules for the regulator(s) of the province(s) where you want to sell the software and your province of residence. APEGA (Alberta) requires at least some engineering software to be authenticated (stamped) by a P.Eng.

APEGA has recently released an authentication standard that includes a test for determining if an output requires authentication:

https://www.apega.ca/about-apega/pu...elines/authenticating-standard-available-now/

Based on the information you've given, the software likely contains technical information (presumably, equations/models that describe reservoir physics and transform inputs into engineering outputs), so the answer to the first question would be yes.

The software (and incorporated equations) is complete for the final intended purpose of the software (this is not a beta version of the software for others to review/test), so the answer to the second question is yes.

You mentioned that the engineering outputs of the software are intended to aid users in making [engineering] decisions, so the answer to the third question might be yes. This point could be debatable, especially if you add disclaimers that the outputs of your software should not be relied upon for making reservoir engineering decisions, but I would not be surprised if APEGA would answer it as yes despite any disclaimers.

One option would be to have another P.Eng. review and authenticate your software. This P.Eng. would be taking professional responsibility for it, so the review would have to be thorough and would likely be expensive, and may not be a practical option for you.

 

[Craig_H]

I would be very interested to hear APEGA's interpretation of the flowchart that jmec87 posted. I would be inclined to interpret it slighly differently at first blush:
Technical Information -> Yes
Complete for Final Intended Purpose -> No

I would argue that a software output is not complete for its final intended purpose. Engineers have a responsibility to validate software that they use. It's a tool that assists in their work, nothing more. If "engineering" is just inputting data, pressing the "run" button, and blindly relying on software outputs, then the profession is in a bad place.

Software outputs, in my eyes, are unverified results. These outputs must be verified, interpreted, and then summarized into a useful work product. That final work product is what needs to be authenticated (stamped). When an engineer authenticates a work product that incorporates software results, the engineer taking professional responsibility is not only taking responsibility for the software inputs, but for the software results as well. As a professional, if you don't verify your software regularly, you are taking some pretty huge risks.

This comes from a perspective of someone who uses software rather than from someone who makes it. I could be off base. Looks like you're a Newfie, maybe your regulator has practice advisors who could provide an opinion? I've used Alberta's and BC's practice advisors and they were helpful (especially BC's).

 

[IRstuff]

A professional work product (PWP) is an output that requires authentication and validation. Defined in the General Regulation as “…plans, specifications, reports, or documents of a professional nature,” a professional work product (PWP) is any output of professional services with technical information relied upon by others, internally or externally, to make a decision or to take action.

Software, in of itself, is not "plans, specifications, reports, or documents of a professional nature," but its output is used to create such products. I think the burden of authentication on the "licensed professional" user of the software. Otherwise, any software tool relied upon by a licensed professional would have to be authenticated, including Excel, any CAD program, or any FE analysis/modeling tool, etc. Hard to imagine how much effort it might take to "authenticate" ANSYS, nor can I imagine any single PE's insurance willing to accept an open and unbounded liability risk for ANY error in the software that might cause ANY harm in an unbounded future with unbounded users

The out is APEGA's definition of authentication

Authentication (Physical and Digital)
Authenticating a PWP means an APEGA licensed professional has completed or reviewed the work and accepts professional responsibility for the engineering or geoscience involved.

TTFN (ta ta for now)
I can do absolutely anything. I'm an expert!

https://www.youtube.com/watch?v=BKorP55Aqvg

faq731-376 forum1529 Entire Forum list

http://www.eng-tips.com/forumlist.cfm

 

[GregLocock]

All the software I use for legal purposes has a EULA that basically says the software provider has no responsibility for anything at all and that it is all on the user. I'd add that anyone running a model and uses the results directly, without checking them, for a production design is insane. As soon as you've asked "Is that reasonable?" then the answer to the second test is No.

Cheers

Greg Locock


New here? Try reading these, they might help FAQ731-376

http://eng-tips.com/market.cfm?

 

[AngieMa]

Thank you all for the inputs. Very much appreciated.

jmec87,
Thanks for pointing out to APEGA and their requirements (PWP). Do you know if other provinces (e.g., BC.) have something similar?
This is PWP definition quoted from the APEGA standard:

A professional work product (PWP) is an output that requires authentication and validation. Defined in the General Regulation as “…plans, specifications, reports, or documents of a professional nature,” a professional work product (PWP) is any output of professional services with technical information relied upon by others, internally or externally, to make a decision or to take action. A PWP can be physical (e.g., paper, plastic film), electronic (e.g., electronic document,image), or digital (e.g., software, modelling, simulation, or any other computer application that cannot be reproduced in a physical or electronic format). See the authentication test in Section 3.1 when assessing whether an output is a PWP.

To me "make a decision or to take action" is ill defined being not sufficiently narrow. Some actions have impact some others not. For example, if I do check a pressure based on Excel spreadsheet calculation and based upon that output I would decide to call a vendor to double confirm the information, this is decision followed by action. But does this really need be controlled by regulatory framework? Now if I use a spreadsheet output to calculate some settings for a pressure safety valve, this is process safety related, it is different, yet constitute decision followed by action.

In regard to the statement of the APEGA specification that says: "relied upon by others... to make a decision or to take action". This exactly what my software is not: anything except a product to rely upon for making a decision. You already mentioned this point. So, if any user relies upon my software outputs, despite all disclaimers in place that they agreed upon by signing an EULA upfront, then I think it would be fair to say that the responsibility is entirely with the user and not with the producer of the software. If APEGA sees it differently, what is the rational?

But then, by extension, any excel template, say most basic one for doing rough calculations also falls under section 3 of the standard. Does this mean that all Excel engineering spreadsheet used in industry in Alberta is/has been certified/stamped by P.Eng ? ... And what about big software (IRStuff rightly mentionned ANSYS), for example Hysys Aspentech that is widely used in oil & gas, it contains massive, really massive number of procedures, how a review could be both conducted and be genuine at the same time (By the way, how the review is conducted is not precisely defined, what is needed to be verified? that the formulas/methods are acceptable to certain X standard that maybe does not exist or that the software has been coded conform to the formulas? I am not shooting the messenger, just sharing my concerns.

Other issues concern intellectual property, to what level do I have to disclose trade secrect methods and procedures, especially if not protected by patents?

 

[Craig_H]

You've correctly pointed out that APEGA's definitions are quite broad. I've found a relative theme to this, at least in Alberta, with regulators expanding their jurisdictions as broadly as possible. It's probably a result of several factors, including the relevant legislative act not addressing limitations clearly, the heads of the regulators getting an ego boost by empire building, etc.

I'd call your regulator(s) and ask for a clarification. You've got plenty of cannon fodder from this thread regarding other software packages that are widely used in the province and that surely have not been reviewed and authenticated by a local P.Eng.

I would hazard a guess that software that meets the authentication requirements would be something like avionics software. Pilots take avionics output and rely on it wholeheartedly when flying under instrument conditions. They have no means (and no time) to independently verify the outputs prior to relying on them. I'd argue that's a distinguishing trait between software types, and a good litmus test for authentication.

 

[IRstuff]

The APEGA document is mostly concerned with software that's part of a product, like a building control/management SW.

https://www.apega.ca/about-apega/publications/standards-guidelines/authenticating-standard-available-now/[/URL]]If classified as digital PWPs, the original or modified versions of the program or code (whether physical, electronic, or digital) and any control philosophy, trip or logic diagrams, logic functional descriptions, cause-and-effect diagrams, Scientific Apparatus Makers Association diagrams, control narratives, commissioning plans, and commissioning results must be authenticated as described in the permit holder’s PPMP. The licensed professional and the Responsible Member must ensure authentication and validation occur when the PWP is complete.

TTFN (ta ta for now)
I can do absolutely anything. I'm an expert!

https://www.youtube.com/watch?v=BKorP55Aqvg

faq731-376 forum1529 Entire Forum list

http://www.eng-tips.com/forumlist.cfm

 

[jmec87]

ANSYS and other engineering software that has been engineered outside Canada might meet APEGA's definition of a "Commercial Off-the-Shelf Engineered Good", allowing it to be used by a Canadian engineer without authenticating it, unless you are incorporating ANSYS itself (not results from ANSYS, but the program) into your own program or are using ANSYS in a way that deviates from ANSYS's published specifications (see section 3.4.1 of the APEGA standard).

The PWP definition clearly includes "software, modelling, simulation, or any other computer application that cannot be reproduced in a physical or electronic format", so there is no general exclusion for software.

I agree that "relied upon by others ... to make a decision or to take action" is not clearly defined for this situation. The engineer is not directly relying upon your software to make a decision or take action. However, the engineer may rely upon the outputs generated by your software to make decisions or take actions. If the engineer wants unreliable numbers, there are free ways to get them without buying your software. What is the use of the software if its results cannot be relied upon?

But I realize that this "relied upon" is complicated. The engineer may use your software to generate ideas for operating parameters to try and then use other programs/calculations and their experience to decide whether or not to use these parameters. The engineer should not be blindly relying solely on the outputs of your software, but the engineer may be relying on the outputs of your software in combination with other simulations/calculations/experience to make their decisions and take actions. I don't know how to draw the line here, especially when you're selling the software and can't control (beyond the EULA, although you can't control compliance to the EULA) how it will be used. Maybe regulators will accept disclaimers in the EULA as a way to draw the line - I don't know.

I think that engineering regulators generally have not looked into this type of software in the past. However, as Craig_H stated, APEGA uses broad definitions and expands its jurisdiction as broadly as possible. If you ask APEGA about your software, I expect that they will say that it requires authentication, but the only way to know for sure is to ask them.

 

[IRstuff]

ANSYS and other engineering software that has been engineered outside Canada might meet APEGA's definition of a "Commercial Off-the-Shelf Engineered Good", allowing it to be used by a Canadian engineer without authenticating it, unless you are incorporating ANSYS itself (not results from ANSYS, but the program) into your own program or are using ANSYS in a way that deviates from ANSYS's published specifications (see section 3.4.1 of the APEGA standard).

By the same token, the software under discussion is not a PWP, since it is not incorporated within any deliverable product, only its outputs.

The PWP definition clearly includes "software, modelling, simulation, or any other computer application that cannot be reproduced in a physical or electronic format", so there is no general exclusion for software.

Note that the wording "application that cannot be reproduced in a physical or electronic format" is not applicable to the output of the software. The PWP is clearly addressing a software deliverable, as indicated in the section I cited; a deliverable software needs to have documentation of source code, algorithm description, etc. The software in question is not a deliverable, per se.

TTFN (ta ta for now)
I can do absolutely anything. I'm an expert!

https://www.youtube.com/watch?v=BKorP55Aqvg

faq731-376 forum1529 Entire Forum list

http://www.eng-tips.com/forumlist.cfm

 

[AngieMa]

ANSYS and other engineering software that has been engineered outside Canada might meet APEGA's definition of a "Commercial Off-the-Shelf Engineered Good", allowing it to be used by a Canadian engineer without authenticating it

Generally speaking, looks like this "Commercial Off-the-Shelf Engineered Good" thing is because the (economic) interests at stake are different when it comes to ANSYS or equivalent system. In this case, the benefits (not limited to but including for example more work for P.Eng to review/certify a software) would be neutralized/dwarfed by the potential consequences of subjecting any of these reputable/proven software and firms to regulatory burdens.

What is the use of the software if its results cannot be relied upon?

User can access reliability by themselves based on thorough review of the results, comparison to other reference/benchmark, analysis of procedures and sound engineering judgment. But it is their responsibility. Reliability cannot be claimed (1) because the software has not (yet) undergone expertise by industry (and I do not mean beta testing) and (2) because I want to opt for most conservative approach that would push the user to check/work against experience/empirical/tested data as best approach toward reliability. You could say the software is of zero added value and I am fine with that - user just do not have to sign the EULA. I explicitly claims the weaknesses and limitations of my model and assumptions. Moreover, at this point I am not even considering billing the user for software outputs but instead for software services (IT maintenance, hosting costs, etc.) just to cover running expenses for the phase being. Despite all these measures, I suspect doing business is going to be tricky in these conditions. Looks like I have to evaluate what my options are. Maybe a US Delaware company?? Would have to see.

Thanks to all of you for the precious help.

 

[RRiver]

Interesting. I know more than a few software engineers designing automotive PCM's\ECU's in the same position as you except they're intentionally in the same position. In fact I think if you looked in to it you would find that most places offering bespoke ECU's you would find most of their software designers work this way. If asked, each of them will give their own personal and professional reasons for working this way but there is one consistent reason they have. Money. By tying themselves to the already established performance automotive electronics and software companies they are bypassing the time and headaches that come with establishing their name and reputation in the business. Considering the potential cost of a bespoke ECU exceeding $100k and updates exceeding $20k they know they would never recover their loses that would come from independently striking out on their own. Regardless of the reality that they can offer the same product now they would only get a small fraction of the cost of the exact same ECU because the companies interested in bespoke ECU's see these costs as small compared to their total investment and to them an unknown is a risk that's not worth it.

Usually about once a year one of the regional universities holds a seminar on software development and bringing it to market. A friend of mine who teaches CAD and FEA at a local community college left Honda where he developed EFI systems for their motorcycle racing teams. He wanted to teach. Anyway he attended one of these seminars that focused on CAD and CAD apps for developed systems. One of the things he told me about the seminar was he learned, 99% of the freeware\shareware CAD programs began with big dreams and asperations.

Your question has me wondering if ultimately you may not be financially better off developing an arrangement with someone already with the required registrations and letting yourself and your program piggyback off an existing name and reputation? This would also allow for your program to get some real world experience along with a valuable peer review assuming your software offers more than what's currently available?

 

[IRstuff]

Not sure how it is in Canada, but in most states, such ECU firmware is covered by an industrial exemption, so no civil licensure nor authentication is required, only that required by the manufacturers' internal processes.

TTFN (ta ta for now)
I can do absolutely anything. I'm an expert!

https://www.youtube.com/watch?v=BKorP55Aqvg

faq731-376 forum1529 Entire Forum list

http://www.eng-tips.com/forumlist.cfm

 

[RRiver]

IRstuff, I'm sure you're right and no civil or industry authorities would be involved. The authorities involved would be the likes of the WRC or F1 governing bodies for my example. For them, I think the only limits would be the operating parameters falling within the rules. That doesn't effect my basic premise about what aligning with the limited number of respected reputations can offer someone attempting to break in to a big industry offering little access. I admit I'm assuming the "little access." I could be wrong but from what the given information about what the software does I doubt there are a lot places offering the services that the program would enhance.

 

[jmec87]

In Alberta (and I think the rest of Canada, but I'm not sure), there is no industrial exemption.

 

[RRiver]

I doubted yesterday the industrial exemption here in the US and US states yesterday but wanted to make sure. It's correct that there is no "civil" license required but "required by manufacturers internal processes" is not. There are numerous outside controls and requirements dictating manufacturer processes.

There are numerous regulations, both federal and state, that granted are less than specific but that's because they are identified by something like, "As identified by industry standards." For an ECU, automotive anyway, that is primarily but not limited to SAE.

The ECU's made for every major US manufacturer uses the CAN Bus system designed and owned by Bosch. Inside the ECU there are proprietary circuits or channels under the control of different organizations or businesses. What underlies it all is the firmware operating design and the boot programming which is owned by Bosch and protected by a number of digital and data legal protections. Although an employee may not be required to have any Bosch certifications to access the ECU, many are, it's because they are under the umbrella of the manufacturers certification. Operational certification may not be required for operational designs for things like emission controls, those that do the testing and reporting required to verify emission standards are most definitely certified to EPA and other's requirements. There are many certifications required for those responsible for those reporting as required for compliance certification. The manufacturers name may be on the report but the efficacy of the report is the burden of the person who signs of on the reports.

This just scratches the surface. The potential harm that can happen from real time hacking of ECU's and the coming autonomous driving is really going to expand this. Homeland Security and the FBI want to require a security clearance for ECU work. That's one heck of a certification.

 

[moltenmetal]

AngieMa: I think you're good- the use of the software to prepare reports is professional engineering. The preparation of the software MAY be professional engineering, but you do have a license to practice professional engineering right? You don't need a consulting engineering designation to write software, though you may need a C of A to carry out professional engineering in Alberta as a sole proprietor. So the question is this: is the writing of software related to engineering, itself an act of professional engineering? I'd argue that it isn't, but others may argue differently and the only group whose opinion matters in this is APEGGA's.

Personally I'd have no difficulty risking this, as I think there is PLENTY of software used in this capacity that was written by unlicensed engineers, non-engineers, groups of people with maybe a P.Eng. but no C of A etc., and I see no meaningful enforcement action being taken against any of them.

You're doing the right thing getting the designation etc. And part of getting a C of A, if you need one (don't know in Alberta- know you need to in Ontario) is getting liability insurance. That's something you must do if anyone is going to rely on your software's output, regardless what provisos you put in place to say that it can't be relied upon...