Here is the statement from my textbook that made me confused as to what "instruction profile" meant:
"...new peripheral devices constantly change the nature of
the demand on the system in terms of typical instruction profile and the data
access patterns."" - Computer Organization and Architecture: Designing for Performance 10th edition
When searching around for a definition for instruction profile, I wasn't able to find one. I found results for instructional profiles which are used in teaching/pedagogy, a pdf showing a graph that used the term instructional profile but seemed to not be in computing, but not a definition for instruction profile.
In this context, it is likely that instruction profile means the types, variety, and organisation (the 'profile') of machine-code instructions being executed on the device.
It isn't a term I have heard before, and one I doubt will suddenly jump into mainstream use, but it is really just saying "new peripherals mean that the types of code running on computers is becoming ever more varied".
Related
my app has passed the first review (yay) - but has now been passed to Allion for 'hardware review'.
The issue is that I am not providing hardware, i've provided voice interactions for an open source HA system, which in turn can support 00s of device types.
The Amazon review process was happy for me to provide them credentials to my service, which had access to a subset of device types, to then QA the interactions.
Is this normal for the review process?
Thus far many of the supported services have been direct hardware partners who own their own hardware and cloud. If your integration is done in a slightly different way it may require special instructions to your reviewer that may be different from normal.
I have had further comment from Google. Unless I can provide 1 of every type of physical device that the underlying HA system supports, they will not review, or certify my app. What this tells me is that either Google aren't committed to small SaaS providers & HA enthusiasts, or that this comment is not true. I note that there are several equivalent services listed on Smart home app list, which do exactly the same thing as mine. I rather doubt they provided one of every manufacturers zwave switch/light etc etc. Very disappointing, Amazon have a more welcoming approach –
I need to come up with a CM process for PLC code.
Currently, the system is developed using RSLogix 5000. The build product is a monolithic file that can be loaded onto a PLC for execution and edited directly in the development environment. With multiple developers, this has become a problem. They're stepping on each others changes.
As an analogy, it's as if, when doing Java development, the only wway to edit and save the source would be to load up a *.jar file into your IDE, make the change, and then save it back to the jar file. This is less than ideal.
How can I coordinate changes between multiple developers working with PLC's?
If we are talking about one big binary files, then a VCS (centralized or decentralized) is not the best tool for the job.
An external referencial (a shared disk for instance) where a batch will copy and label the current PCL state is better.
See "Tracking Software History"
To avert discontinuities in the historical record of revisions, old versions of programs must be stored.
“We take it a step further, though. Using our MDT AutoSave, we actually go out and interrogate the equipment. Overnight or at whatever frequency is specified, the software reads the programs in the PLCs and then compares that information to the last known program. The version-control software will copy the new program and store it and [then] compare it to the last one.
Launching version control is fairly simple. Required is software installation and then hardware configuration. “You would need a server and a couple of weeks of engineering and you’re good to go,” Perysyn says. However, his company uses a “shrink-wrap approach” that involves installing the software and then customization by users filling in the blanks.
That being said, when you have multiple changes from multiple developers, you need an integration environment where a first delivery can be done and validated, before pushing it to the actual server.
See also this post.
I use Unity Pro, so this may not apply for other brands.
Unity can export an "archive" file which is XML which describes the PLC program and IO setup in its entirety. After commissioning changes, I create an export and check it in to my local Git repo. This gets me an annotated history of changes, but no visual comparison. I can always use UnityDiff for comparison.
Check out http://www.mdtsoft.com/ also
You need specialized versioning system for PLCs like VersionDog.
From the manufacturer:
"Special support with Smart Compares for SIMATIC S5, SIMATIC S7,
SIMATIC PCS 7, WinCC, WinCC flexible, InTouch, CoDeSys, TwinCAT,
Phoenix PC WORX, RSLogix, Schneider Modsoft, Schneider Concept,
Schneider Unity, SINUMERIK 840D, Bosch IndraWorks and more. Also robot
programs from ABB and Kuka and office related data formats like
Microsoft Word, Microsoft Excel and Adobe PDF are perfectly supported
by versiondog.
Update: Here is a screenshot showing ladder version compare. I guess that's what most PLC folks are interested in. We also use it to schedule e-mail report if PLC offline and online application versions are a match, as an alarm that something has been changed in PLC but not put into version control server.
About RSLogix5000 specifically, I have seen developers use an emulated PLC and make their changes online. The final product once developed is then put together with all the comments (as they are not contained in the PLC) and then commissioned. There are issues with changes that cannot be done online, such as AOIs. There are tools in place to stop two people editing the same logic online at once and to take ownership of sections. Backups can be done in the form of uploads, but there isn't any way to track changes.
It is a messy problem, messier still for when you are maintaining a system as you want an .ACD that you can go online with, as unless you are somehow doing a diff with the RSLogix compare tool you just see unreadable machine code like "+|Éû³´¬ÙÆW×晵‚>Ù,"
The most common revision control I have seen (sadly) is just saving the the latest file, then taking a copy and adding the current date to the file name, like the recommended control.com post described.
RSLogix5000 has always prohibited multiple users from opening and editing on the same .ACD simultaneously. However, if multiple users have identical .ACD files, open them, and all make connections to the same target controller, they each can edit on the controller simultaneously, but only if they are working on different routines. Other's edits appear automatically, if they were to look at another programmers routine.
Note that working online like this is usually done with the PLC running, even sometimes with the target system (some kind of machine) operating. This kind of arrangement for the purpose of completing work faster, or in some cases because the system is huge. No one develops like this, as it is really a debug tool and impractical for significant changes.
If one programmer finishes, and another is not done, the unfinished work of the other will be saved to the first programmer's .ACD when they save. Whoever saves last will have everyone's work.
Like others have mentioned in this thread, using file date is fairly reasonable. Some companies use a version control variable that is usually displayed on a connected HMI. Other companies use a separate document that documents who and what changes. Sometimes version notes are placed in a lengthy rung comment in the main routine.
My company uses a separate change log, and dated archive copies are maintained. Multiple programmers are only used in the most extreme cases. Someone is always designated to maintain the offline file integrity, usually the person who will be working the longest, or the project manager.
It is important to note that rung comments are not carried from one user to another before RSLogix5000 v21 because previous versions didn't store comments on the controller.
All this said, you might be trying to manage offline development. I haven't seen any sophisticated methods for this. Usually programmers write the needed routines separately, and a project manager will assemble them into a single project. The cleanest approach I've seen is where a project manager will create an architecture with global functionality, and assign routine work to others, giving them a copy of the .ACD to work with. They return the .ACD with changes, and the project manager copies and pastes their routines into the "master" project.
This is a very good question and it really depends on what you want it to do.
If you are only using Rockwell equipment it might be helpfull to look at their solution, I think it's called FactoryTalk AssetCentre.
Currently I am looking into using Bazaar from Canonical.
One thing that VonC pointed out is that a piece of software that can interogate the PLC is a deffinate plus, not a must in my oppinion but it sure as hell helps.
Am I reading your question properly and you have multiple developers working on the same PLC code at the same time? It's a scary thought but I know it sometimes needs to happen, Siemens PLC's are a bit easier to program with multiple developers but I would assign one person to consolidate and test all the changes before committing to the PLC. Any CVS system will let you create branches for every developer but how you would get them to consolidate their changes is the million dolar question.
Bart.
A simple thing to do would be to do a text diff on the .l5k files so you can easily see whether a developer has been messing with part of the file that is outside of their scope.
I saw this question just now from a link at stack exchange: Are There Realistic/Useful Solutions for Source Control for Ladder Logic Programs. Rather than have a link only answer, I'll dupe my answer here:
There is actually a canned solution - from GE-IP of all places. Check out Proficy Change Management. This product does version control from a PLC control systems point of view, rather than a pure version control of files point of view - it works as a layer sitting on top of a VCS (the scary part is that originally this VCS was Visual SourceSafe) and handles rights management, reporting and checkout/checkin.
While the product is from GE-IP, it is designed to support a variety of PLC and HMI systems out of the box.
Full disclosure, I used for work for a company selling and installing PCM (but that was 7 years ago). So if you ask me what it was like back then I'm likely to tell you where it all went wrong!
In my company we just started a trial with Copia.io
Check it out. Our first tests look very promising!
It brings, branching, merging, ladder diff etc... for multiple PLC platforms (Rockwell, Siemens, Codesys)..
PS. I work for a company that builds machines, we were looking for version-dog alike solutions with a bit more power in collaboration and diffing capabilities. I used tools like Mercurial, Git, Tortoise in past companies (not for PLC though).
Hi
we are expanding one of our projects in a major bank to include access via mobile devices. We are evaluating a few tools - inc. perfecto mobile, experitest and deviceanywhere.
From our initial evaluation perfecto and device anywhere cover a larger set of handsets inc feature phones. Experitest on the other hand is strong and simple to operate with smartphones(iphone, android etc).
Can anyone share experience from using these tools for large scale projects? we are mainly concerened re stability, ability to work with QTP and support considerations (support for new devices etc).
I have used DeviceAnywhere extensively. Perfecto, not that much, after a pretty dissapointing trial period. DA has support/add-ins for QTP and QC. Perfecto does not cover QC. Perfecto is not faster than DA, since most of their devices are in Israel, and not the US. DA has a few datacenters in the US and abroad, hence you have a better chance to get better performance. DA has an pretty long list of Enterprise and Carrier customers...while Perfecto seems like a very small company. Compare their website quality-it's pretty obvious which one looks more professional...You should try them both and make up your mind...
I have used all 3 platforms many times
Only Perfecto Mobile and DA are robust enough for real testers (at least for enterprise level).
DA have more devices but Perfecto are 100% web based, faster and MUCH cheaper. Both offer automation environments with pros and cons but Perfecto offers QTP integration and enhanced security solutions
Conclusion - both systems good, Perfecto cheaper, Perfecto much better for enterprises engaging in mobile testing.
Guido
Think of coupling a standard software remote control product with a standard software test robot (like QTP).
As an alternative, and being a mostly device-independent, but bitmap-dependent solution, you could use one of the many remote controls to bring the mobile's display contents to the desktop. Then, you'd "click around" in that remote control window using you favourite test robot.
Stupid that sounds? Well, it has its strong and its weak points:
If QTP is set for you, you'd be stuck on bitmap synchronization, no other useful GUI properties would be visible. However, if you have some QTP know-how on board, you could reuse all the know-how for test management integration via QC, test data addressing, and so on, scripting "art" like wait-for-the-right-thing, convert bitmaps to text, and so on. You could even "in real time" verify the results displayed on the mobile to stuff in the corporate backend, or research expected results in some central database after doing some transaction on the mobile -- all that would be easy since your test robot runs as part of the IT infrastructure all the time, so it has easy access to those resources. And those accesses could be done with all the comfort we got used to on PC-based test robots, like for example QTP's database checkpoint.
The positive aspect would be: Using such a scenario, you are largely independent of the mobile's technical details, and could support a lot of different devices by just using different sets of expected bitmaps. (Provided the workflows are exactly the same, which of course is not always the case.)
If you don't have to buy an extra test robot, this solution might be unbeatable cheap. Most Windows mobile devices for example can be used with Microsoft's free remote control, and there are lots of commercial vendors offering remote control functionality for a variety of devices in one package.
Also, you could develop test scripts using emulators emulating the mobile device, because the test robot would not know the difference between a display being fetched from the real thing, or being shown by the emulator.
I've done all that with various remote controls and PDA/smartphone devices, using CitraTest or QTP as the test robot. I was very happy not having to mess around with yet-another-specialized tool, or even more than one of them, each with their own language, or methodology.
Biggest hurdles besides the ones already mentioned were:
find a remote control that is versatile, fast and reliable
find a way to let the mobile use its "normal" communication path (for example, cellular connection) for all applications while, for performance reasons (and to minimize side effects), the remote control is connected through a direct connection (USB, propretiary synch cable, network...whatever the mobile supports).
create a scripting "standard" which is sufficiently exact to keep test robot and mobile app execution synchronized while avoiding re-capturing expected bitmap for all supported devices too often (this can be partly automated)
timing problems -- when you are on the bitmap level, it is hard to tell if you waited "long enough" for some message to appear, disappear, or whatever.
cover exotics like "app continues only after you took a photo with the mobile camera". Generally speaking: Control the built-in periphery (what a contradiction...) of the mobile (in my case, I had to make the barcode scanner "see" specific images -- quite difficult and usually very device-dependent to automate)
It's feasable, though, and such a solution can be very stable and realiable, with a sufficient grade of cost-efficiency in terms of test maintenance effort (depending on what changes how frequently in the app-to-test, of course).
jQuery runs a lot of tests automatically on both feature phones and smart phones, maybe you can use their test system. As a side note, check if jQuery mobile is for you, it seems very cool.
To the best of my knowledge Perfecto Mobile has made some major improvments to its offering and currently offers some major benefits over the others, including price. In the last few months they've added popular devices like Lenovo nePaone. You can see the full list om their website:www.perfectomobile.com. Since they use differentontrol technology than Device Anywhere they are capabable of supporting new devices really quickly. Regarding stability and QTP they also have many advantages over the others. For instance, tools to record your own specific user scenarios and test them repeatedly across devices - this is a great automation tool for large scale projects.
If you are testing bank application you should consider the security issue.
How do you protect your application and application data. Once you release a phone, someone else can get control over it.
My recommendation is to use the on-site capabilities I believe all the above solutions have.
I'm scratching my head over this.
I have a moderately successful app which has a free "LITE" version in addition to the full one. This is a utility app, not a game with levels, and I'm having trouble figuring out what Apple will accept for the lite version. The reason this is now an issue is that I've brought both code bases together with different targets and my new improved lite version will be iPad compatible as well.
There are two fundamental differences in the versions. In the lite version, the data displayed is only displayed for the current day, whereas the full version allows users to choose any date. Additionally, one of the data screens shows 3 data points in detail, whereas the full version shows much more. The lite version is perfectly functional in its own right and has no greyed out features.
What I would like to do is use the spare space on the lite version data screen to explain that more data is available in the full version and offer a button to upgrade, however I can't figure out if Apple will classify this as "upselling" (well how else am I going to mention the full version?) and from reading the new app store review guidelines, I was disappointed to note that absolutely no further clarity seems forthcoming from Cupertino in this regard. All the examples I find from Apple are games with additional levels and this simply doesn't match a "utility" application.
Is there any recent advice on what is and what is not allowed? I'm aware of not having greyed out functionality and nagging the user - but does having an upgrade button on one of the tabs (in the case of the iPad in a popover) count as nagging? Am I allowed to mention the additional features in the premium version or does that count as upselling? If not, what can I actually say?
Clues welcomed!
Frankly speaking, there is no way to be 100% sure without submitting the app. There might be someone who have already tried this and get rejected. It's not very easy to be sure. But as a user personally I won't be happy to see the upgrade button in every page. Rather I would like to get the summery of full version in a different page. This might not be a better design to have an upgrade button in every page, though this is my personal opinion. Apple gives importance to be consistent with the convention, and the convention is to have different upgrade page, I think.
You can download a number of lite apps and check whether any one has done this kind of thing. The policy should be same for both game and utility. If after checking many you don't find a single one, then you should reconsider this. But yes, you can't be 100% sure.
The rules appear to be inconsistently applied.
I think it boils down to the perceived difference between "Ha! You don't get $feature unless you pay us!" and "By the way, we also offer $more_expensive_app with more features." The two are effectively the same thing, but they leave a different impression. Yes, it's a big grey area — I've seen apps across the spectrum (I don't recall any persistent nagging/mentions, but certainly "buy $full_app to get more levels").
"Other apps by $company" might be a good way to go, perhaps in an "about" tab or similar.
Reviewers are also far from consistent. Before Apple did any "private API" checks (they didn't seem to until mid-2009; apparently not even the frameworks you linked to which is dead easy), private API usage was determined by whether your app did anything in $list_of_suspicious_behaviour, which seemed to be applied inconsistently by different reviewers.
I've also used "$full_app" because that's the impression I got; I think part of the guidelines is that you're not supposed to give the impression that your app is not "full". I also hate crippleware (artificially limiting a feature, e.g. a navigation app limited to 8 waypoints and telling you to buy the full version if you want more, as opposed to simply not including a feature), but Apple doesn't seem to mind.
Apple allows ads in apps if they are presented in a reasonable manner.
Developers can choose which ad network to run, even from competitors such as admob.
There's nothing to say you can't be your own ad network.
Just make sure your ad for your products (which occasionally just so happens to be an ad for the full version of the same app) follows the same presentation rules as the ads for admob, iAd, etc. follow. Your own ad network may or may not be the campaign you choose to run during the review period.
Do we create services when we write programs, or are they commodities?
Are we like window-washers in that our programs(actions) provide some services to the users?
OR: are we like carpenters in that our programs(products) are sold and used by their new owners?
Or should this be seen in different aspects: The act of programming being a service, and the resulting program is a product?
The above has a direct impact on the following question: Is it theft or fraud when you copy software that you have no rights to? Theft is the physical removal of an object of value from the possession of another; fraud is representation of a falsehood in such a way that leads to the economic loss of the victim (the representation here being your assumption of right-to-copy).
It also impacts on questions of causal liability: If the program you wrote to crack passwords are used by others to rob a bank: are you an accomplice? If your program is a service then it could be argued that you are; if a commodity then you 'should' be in the clear.
Or: should each program be treated as a unique instance, based purely on the intentions of that program's originator, as to wether it should be treated as a service or commodity? Or should the user's intentions be used?
How does this reflect on the open-source world where many programs are available that seemingly infringe on commercial rights, e.g.: copy-protection and DRM circumventions?
(This impacts us all every time that we write code.)
It's both actually.
Sometime you sell a product which just works. It's a commodity. A notepad program for example is a commodity, you don't go into any relationship with its author. Most small tools fall into this category.
Sometimes you develop a custom application tailored for your specific user, or you integrate an existing product with their legacy applications and adjust it to work for their specific situation. It's definitely a service and you are usually in a long-term relationship with the customer. Most 'big'/expensive programs fall into this category. You could buy MS SharePoint Server license as a commodity but in most scenarios most likely you will also buy a service of someone to make it work for you.