I would like to understand that in the context of Artificial intelligence, is there anything called as rule based ai or is it just equal to any automated system. When i read about rule based ai it sounded nothing different from automated systems. If rule based ai is same as automated system , can it be concluded that every automated system is a kind of rule based ai ?
Automated describes systems which operate without manual intervention in general.
Rule-based describes a particular architecture of automated systems where behavior is specified in terms of if-then rules, also known as productions.
Related
I have the following Questions About embedded unit testing:
Can Google unit testing be used for embedded C Code?
Is Google unit test compatible with IEC 62304?
I tried to find a document, which could answer my Question but unable to find that. Even in the Google Unit Test Official Documentation1, I was not able to find the answer. Also, I have the following Question:
How would I know an open source Unit Testing Tool is compatible with IEC 62304 Standard?
Please help me with your Knowledge in Unit Testing.
Thanks in Advance.
To answer your questions directly:
googletest is intended for use with C++. The link in Vertexwahn’s answer shows that at least one person has been able to use it for testing C.
2 & 3. IEC 62304 is a software life cycle process, it has nothing to say about whether you can or cannot use a particular tool, only the steps which you must go through in your project.
Unit testing is certainly one step that you would go through in your software life cycle. As the engineer responsible, it is your job to decide whether or not a tool is suitable for a particular task. No person outside your project can ever tell you that a tool is suitable for use in developing a particular medical device, because this depends very highly not only on the design of the particular device, but also on the testing strategy that your are going to adopt.
The testing strategy in turn will depend on the particular risks that you need to mitigate. You will need to follow ISO 14971 for your risk management process.
At every stage of the process you will have to document the reasons for the decisions that you have made according to an ISO 13485 quality management process.
When you come to make a regulatory submission to an approved body they will appoint an auditor who will look through your documentation. In the vast majority of cases the auditor will have absolutely no technical expertise in software. They will check that you have followed the appropriate documentation process but ultimately they will take your word on whether or not a tool is suitable.
It is easy to trick an auditor and use an unsuitable tool by creating a large volume of paperwork which falsely explains why it is suitable. If you do this no one will know until or unless the medical device causes harm to someone and your company (or you personally) gets sued or prosecuted and the documents get examined by technical experts appointed by a court.
What you need to think about when you put your signature on the document that states the tool is suitable is whether you could stand up in court and defend your decision after someone has been harmed.
After all this, having said that no tool is ever either inherently suitable or unsuitable, there are some software suppliers that make claims of suitability or even "pre-approval". What this means is that they have pre-written many of the documents that your regulatory submission will require. These are always very expensive (nothing free like googletest fits into this category). Even if you use these pre-written documents, it is your responsibility to review them and put your signature against them and say that they are correct and more importantly that they are applicable to your specific project. Buying a product like this saves you time, but not liability.
GoogleTest seems to work with C -> https://meekrosoft.wordpress.com/2009/11/09/unit-testing-c-code-with-the-googletest-framework/
Google will not take over the responsibility for you to be compliant with IEC 62304 regarding your use cases. You have to make sure that the tools you use do what they should do for the use case you use them. For instance, you can come up with an acceptance test for GoogleTest that proves that it works for you as expected.
When doing this consider also known bugs. Even if a company offers you a unit test framework that is IEC 62304 compliant I would ask myself if this test framework has more users and is better tested than gtest.
I think something like this does not exist - it would mean that the Open Source project would take over the liability for damages resulting from its users
I've been trying to do some research on rule-based AI, but I can't seem to find a great distinction between production and expert systems. They both use rules to dictate their decisions and they can both use forward or backward-chaining. Yet, they are talked about as if they were seperate entities.
Also, I can't seem to find anything else that fits under the "rule-based system" umbrella; is there anything else?
Any insight on this is greatly appreciated. Thanks!
A production system is a type of programming language. An expert systems is a type of program.
Production systems are a form of declarative programming where you specify what you want done, but not how it is done. Declarative programming works best when your program can be naturally expressed using productions/rules (when/then) and you need to be able to frequently add or delete productions. For example, many email programs allow you to add rules for processing emails when they arrive. It is convenient to use productions/rules for processing emails since what you want done can be expressed naturally as productions (when subject contains "nigerian prince" then move message to junk mailbox), but since you will be adding/deleting productions it is also convenient to maintain them in this form and to allow the process of how the productions are applied to be automatically handled for you.
Generally expert systems refer to programs that emulate specialized human expertise (for example diagnosing diseases). Such expertise can frequently be expressed using rules and can be incrementally added or removed, so these types or programs are often implemented using production systems since it is convenient to do so.
So while production systems have a strong association with expert systems, not all programs written with a production systems are expert systems and not all expert systems are written with production systems.
I am usually a wood worker and not a developer. I'm learning C/C++ for embedded systems while trying to make some of my tool autonomous to save me hours of repetitive work.
For now, its fun and going well, I have spend maybe a hundred of hours coding/learning and already saved more time*.
As I want to keep going is buying and following MISRA coding rule a "mandatory good idea"? What does MISRA contain? Only coding rules, or kind of tips to make it safer?
Those tools could be dangerous (after all they cut wood and a human body is far less resistant...).
Note: I obviously do my test in 4 steps:
Just the pic running with an OSD & SD card logger (one day I'll make an anylze tool and stop reading those).
I plug the tool with nothing on it
I use soft drill/cutters on foam
I conduct real test at good distance with my hand on the emergency stop button.
Also I'm the only employee and no one else has access to my work-place.
*for now I've turn a drill into a kinda 3D wood printer (doing the not precise part of the work), and a "cutter-board" into an automated one.
Note2: I'm not a native speaker so tools' names are probably off.
MISRA is designed originally for use in the automotive industry, though it has grown well past that at this stage. The MISRA guidlines stated aims are:
Ensure safety
Bring in robustness, reliability to the software.
Human safety must take precedence when in conflict with security of property.
Consider both random and systematic faults in system design.
Demonstrate robustness, not just rely on the absence of failures.
Application of safety considerations across the design, manufacture, operation, servicing and disposal of products.
The documents mainly consist of rule based advisory information for code that tries to meet these aims. MISRA document prices have dropped somewhat over the years, some documents can be bought online from MISRA for as little as GBP £10 + VAT.
However, as a beginner and amateur coder, I would advise first bolstering your knowledge of C and C++. While in most areas of industry it is often good to follow a pertinent standard, if applicable, the documents are written with the assumption that the reader has a very solid grounding in the languages and also in the concerns and processes governing full-scale commercial type applications written in them. If your workshop is for personal use only, and depending on rules governing workplace safety in your jurisdiction, I can say that having a good understanding of the languages, language tools and the hardware would allow you to start making good choices with regards to how to code things more-so than reading MISRA could at such a stage in.
As commented above, and it is worth reiterating, MISRA is not some kind of magic wand or concrete way of going about things that will guarantee your code is good, works and is safe. Both good and bad code can meet standards. Following MISRA before having a good and complete grasp of what you are doing might be the same as ensuring every cable in your work shop is neatly tacked in place but then stabbing yourself with a chisel.
MISRA-C is a set of rules which will enforce you to weed out well-known problems and poorly-defined behavior from a C program. It is a "safe subset" of the C language, banning various forms of dangerous practice through rules aiming for well-known bugs such as reliance on poorly-defined behavior or implicit type conversions. C has the advantage of being a very old language, meaning that all the language flaws are well-known.
MISRA-C has a heavy focus on static code analysis to find bugs at compile-time. This is something to keep in mind, as to my knowledge there exists no open source static code analyser tools that can check for MISRA-C compliance. The commercial tools tend to be very expensive and often also full of bugs/false positives. Still, most of them are useful.
MISRA-C is only focused on C programming, it does not address CPU or microcontroller issues etc, although it does enforce some forms of defensive programming, which is a counter against EMI, run-away code and other forms of unexpected program behavior. (For a list of general tips & tricks beyond C, see this. Not all of these will necessarily apply to your specific machine though.)
To demonstrate MISRA compliance, you create a "compliance matrix" which shows how you catch every directive/rule of the MISRA-C document: through compiler messages, peer review, static code analysis etc.
Most rules in the document make a lot of sense, but some do not. MISRA-C does however allow deviations from most rules, ranking them as one of:
Mandatory. No deviations allowed.
Recommended. One must invoke a formal deviation procedure if not following the rule.
Advisory. One can deviate from the rule without making a formal deviation.
Typically, creating MISRA-C compliance is therefore done by establishing a company coding standard, which addresses all rules. The easiest way to implement it is write down in this document which rules that are followed and which ones that are skipped, on a company level. Then set static code analysis filters accordingly.
There's any pattern or modeling technique to store business rules in database?
I'm looking for something that gives to my system business rules the same extensibility that EAV (Entity-Attribute-Value) gives-me in terms of fields.
"Business Rules" is one of those phrases that change meaning depending on who uses them. I'm assuming that you mean firstly that you need a way of executing logic in your application that applies to every business transaction, that can be managed by non-technical people, and that allows those rules to change over time.
If that is the case, the common architectural solution is to integrate a business rules engine, rather than build this yourself. It's a non-trivial problem - modelling the business domain and picking the points where rules may be applied is hard enough, but then write a domain-specific language for those rules, in a way that end users can modify through a user-friendly GUI without slowing the system to a crawl is hard.
Examples of business rule engines are Drools and Visual Rules. Both are fairly involved pieces of software - worth reading up and making sure they are what you need!
My boss asks me to write only ANSI SQL to make it database independent. But I learned that it is not that easy as no database fully ANSI SQL compatible. SQL code can rarely be ported between database systems without modifications.
I saw people do different way to make their program database independent. For example:
Externalize SQL statements to resource files.
Write many providers class to support different database.
Write only simple SQL, and keep away from advance functions/joins.
Do you always write your code "any database ready"? Or do it only if needed?
If yes, how do you achieve it?
You could use one of the many Object/Relational Mapper tools, like Hibernate/NHibernate, LLBLGen, and so forth. That can get you a long way to database portability. No matter what you do, you need to have some abstraction layer between your model and the rest of your code. This doesn't mean you need some sort of dependency injection infrastructure, but good OO design can get you pretty far. Also, sticking with plain SQL and thinking that will get you portability is rather naive. That would be true if your application was trivial and only used very trivial queries.
As for always writing an application to be "any database ready," I usually use some sort of abstraction layer so it is not hard to move from one database system to another. However, in many circumstances, this is not required, you are developing for the Oracle platform or SQL Server or MySQL whatever so you shouldn't sacrifice the benefits of your chosen RDBMS just for the possibility of an entirely seamless transition. Nevertheless, if you build a good abstraction layer, even targeting a specific RDBMS won't necessarily be too difficult to migrate to a different RDBMS.
To decouple the database engine from your application, use a database abstraction layer (also data access layer, or DAL). You didn't mention what language you use, but there are good database abstraction libraries for all the major languages.
However, by avoiding database-specific optimizations you will be missing out on the advantages of your particular brand. I usually abstract what's possible and use what's available. Changing database engines is a major decision and doesn't happen often, and it's best to use the tools you have available to the max.
Tell your boss to mind his own business. No, of course one can't say such things to one's boss, but stay tuned.
What's interesting is what business value is supposed to be supported by this requirement. One obvious candidate seems to be that the database code should be ready for working on other database engines than the current. If that's the case then that's what should be stated in the requirement.
From there it's up to you as an engineer to figure out the different ways to achieve that. One might be writing ANSI SQL. One might be using a database abstraction layer.
Further it's your responsibility to inform your boss what the costs of the different alternatives are (in terms of performance, speed of development, etcetera).
"Write ANSI SQL"... gah!
Just for the record. There is a similar question here on Stackoverflow:
Database design for database-agnostic applications
Being 100% compliant to ANSI SQL is a difficult goal to meet, and yet it doesn't guarantee portability anyway. So it's an artificial goal.
Presumably your boss is asking for this in order to make it easy and quick to switch database brands for some hypothetical purpose in the future (which actually may never come). But he's trading that future efficiency for a greater amount of work now, since it's harder to make the code database-neutral.*
So if you can phrase the problem in terms of the goals your manager should be focusing on, like finishing the current project phase on time and on budget, it may be more effective than just telling him it's too difficult to make the code database-neutral.
There is a scenario when you need to make truly database-neutral code, that is when you are developing a shrink-wrap application that is required to support multiple brands of database.
Anyway, even if you currently support only one brand, there are certainly cases where you have a choice to code some SQL using proprietary features, but there also exists a more portable way to achieve the same result. You can treat these as "low-hanging fruit" cases, and you can make it easier to port the code in the future if the need arises. But don't limit yourself either, use proprietary solutions if they give good value. Perhaps add a note in the comments that this deserves review if/when you need to make a port.
* I prefer the word "neutral" instead of "agnostic" when talking about platform-independence. It avoids the religious overtone. :-)