I do have examples of requirements such as requirement documents and traceability matrices. however they aren't in a readily sendable format. Any interested please send me an email email@example.com and remind me and I will put them up on the web and send you a link.
In creating software archeticture Step 5 slide 19 and step7 slide 21 are the same .... they are supposed to be in order to drive home the point that someone really shoudl be reviewing the architecture on more than one occasion. A second pair of eyes will always catch something that the designer is overlooking! Fresh perspective! One reason code reviews are so important!
Jacob: What does it mean that you're a fan of pineapple? The edible fruit..a band? and hardware platform? I am a fan of the fruit but it's also just a statement of me being quirky. You haven't lived until you've had pineapple mac&cheese ..... it's actually delicious!
The OMG site (http://www.omgsysml.org/#What-Is_SysML) says that "SysML represents a subset of UML 2 with extensions needed to satisfy the requirements of the UML™ for Systems Engineering RFP" UML for Software (works for Systms as well...), SysML for Systems.
Question for Tomorrow ... ? Then does that make "UML a subset of SysML or is it an alternate to or replacing UML or is UML for systems in general and SysML for software? Sorry if I'm getting off topic or confusing things. Thanks ...
You can eliminate test modules for production but I always feel that this is scary! I'm a fan of fly what you test! Who knows what interaction with test code may break! There are times when it is necessary but I try to avoid this if I can!
You could also use ifndefs although I've seen this used and abused to the point where the code is so complex you don't know what is included and what isn't. A few are okay but if there are too many simplify!
I have one called eDraw that I use that I really like. Unfortunately though its only a drawing tool so it won't let me autogenerate any code but it's great for "pretty" diagrams and has a lot of benefecial and common software diagrams pre-built into it.
Removable code modules: Let's say you need engineering data from a system to verify the final design. Is is practical to include modules (along with their sensors, if required) that address this engineering development needs, then eliminate them from the code for final production?
Alaskaman66, you certainly could. You could setup a configuration module that has the parameters for your strain gauges and then depending on gauge adjust your configuration. I'm sure the measurements or the interfaces are similar. The idea would be to abstract the commonalities into a single driver and anything that changes use configuration. If there were certain things that always change you could use a call back function to add specific code.
Re: Jacob's question, additional considerations related to environmental conditions for an embedded software architecturecan include (1) mapping of functionality to different task rates to meet customer requirements while avoiding over-scheduling of the processor and (2) development of a memory map to understand how available data flash and code flash will be used.
Testability! Great point! This is often overlooked and I'm glad that you brought it up! Testability and even adding in debugging and logging capabilities should be in the architecture too not just requirements
In my exprerience, hardware and software requirements definition should occur simultaneously. Someone with a high level view of the entire system needs to define the hardware-software interface before either systems can be developed. Throughout the architecture process, both teams need to communicate to make sure the two systems can work together.
I try to follow IEEE standards for software development. Then reality intervenes and I just start coding, while designing circuitry, working with marketing, and putting out fires on the production floor.
I am trying to transition from Visio (pictures of modelling elements, but no simulation or code generation capability) to Modeling tools that allow for simulation and code generation. Enterprise Architect and Rhapsody have simulation and code generation capability, and also some amount or "reverse engineering" capability.
Say you're constructing an in-house control unit for a solar therman system. Here, some additional engineering considerations might be: 1) don't bother finding the cheapest or smallest microcontroller available; 2)Gui can be invisible, say by host download; 3) use a microcontroller you're familiar with, even if it's overkill
some more reasons: identify key critical components and segregate from generic easy supporting components. this enables focused experimental code to be written early, to prove out key system capabilities
Hi all -Audio is live! If you don't see the audio bar at the top of the screen, please refresh your browser. It may take a couple tries. When you see the audio bar, hit the play button. If you experience audio interruptions and are using IE, try using FF or Chrome as your browser. Many people experience issues with IE. Also, make sure your flash player is updated with the current version. Some companies block live audio streams, so if that is the case for your company, the class will be archived on this page immediately following the class and you can listen then. People don't experience any issues with the audio for the archived version.
The streaming audio player will appear on this web page when the show starts at 2 PM Eastern time today. Note however that some companies block live audio streams. If when the show starts you don't hear any audio, try refreshing your browser. If that doesn't work, try using Firefox or Google Chrome as your browser. Some users experience audio interruptions with IE. If that doesn't work, the class will be archived immediately following our live taping.
Engineers at Fuel Cell Energy have found a way to take advantage of a side reaction, unique to their carbonate fuel cell that has nothing to do with energy production, as a potential, cost-effective solution to capturing carbon from fossil fuel power plants.
To get to a trillion sensors in the IoT that we all look forward to, there are many challenges to commercialization that still remain, including interoperability, the lack of standards, and the issue of security, to name a few.
This is part one of an article discussing the University of Washington’s nationally ranked FSAE electric car (eCar) and combustible car (cCar). Stay tuned for part two, tomorrow, which will discuss the four unique PCBs used in both the eCar and cCars.
Focus on Fundamentals consists of 45-minute on-line classes that cover a host of technologies. You learn without leaving the comfort of your desk. All classes are taught by subject-matter experts and all are archived. So if you can't attend live, attend at your convenience.